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Foreword 


“So you're the one who decides what color a box of detergent should be?” 


That’s how one Silicon Valley veteran responded years ago when I told him I 
wanted to switch from engineering to become a product manager. It was the 
early days of the dot-com era, and in truth he was right. As you'll learn in Chap- 
ter 1, for many years that was what product managers did. But as the role of prod- 
uct manager expanded into high tech, it adapted and evolved, meaning different 
things to different people. At some companies, product management was pri- 
marily an outbound marketing function. In others, it was more technical. Some 
companies used the term program managers for their product managers, others 
called them project managers, but called their project managers program managers. 
(Even more confusingly—everyone just called them all “PMs.”) 


In the almost 20 years that have passed since that conversation, product manage- 
ment has matured. Today, in the digital world where we hardly agree on much, 
just about everyone can agree that product managers are essential contributors at 
the intersection of business, technology, and user experience. Thanks to success- 
ful product-first companies such as Microsoft, Google, and Facebook, people 
seem to finally be speaking the same language. Every year I’m contacted by hun- 
dreds of college students hoping to begin a career as a product manager. That’s 
awesome: when I was a college student I didn’t know what a product manager 
was. (Heck, I’m not sure I even knew when I became a product manager.) 


As the technology industry coalesced around product management, a new prob- 
lem emerged: how should you lead product teams? For me, making the leap 
from software engineer to product manager was challenging enough, but it was 
even harder to go from being an individual contributor product manager to prod- 
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uct leader. Shifting from managing products to leading people managing prod- 
ucts felt like uncharted territory. You need to be a people-first communicator 
who can rally everyone behind a vision without much formal authority. Leading 
people is hard enough, but leading product managers? Let’s say I made a lot of 
mistakes and leave it at that. 


Well, good news friend. No matter whether you’re a product manager, a new 
product leader, a startup founder, a CEO, or a CTO, your path is going to be 
much easier than mine was. The book you’re holding in your hands will be your 
guide to navigating product leadership, the one I never had. Many of the books I 
found on leadership had solid advice, but didn’t fit cleanly into the rough-and- 
tumble world of product. Within these pages you'll hear a diversity of opinions 
from the industry’s most successful and respected product leaders, insights that 
will help you lead your team and deliver exceptional products. 


There is no one right way to build great products; but as we see from the sheer 
variety of product leaders interviewed and represented in this book, there is a 
right mentality and approach. You'll still make lots of mistakes—everyone will. 
But after reading this book, you won’t make the same ones I did. 


—Ken Norton 
Mountain View, California 
March 27, 2017 


Introduction 
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In today’s lightning-fast technology world, good product management is critical 
to maintaining a competitive advantage. Product leaders have become increas- 
ingly central to company success, with their choices, decisions, and actions 
intrinsic to the achievement or failure of the business. Product management 
teams are growing quickly, yet their roles and responsibilities are still poorly 
defined. As with any fast-evolving market finding, developing and guiding suc- 
cessful product leadership is a major challenge, further complicated by the fact 
that product leaders tend to have all the responsibility for success and failure, but 
little authority over the assets and resources necessary to deliver those outcomes. 


We see product leadership as being both distinct from and inclusive of product 
management. As we'll discuss in this book, leadership often comes with a lot of 
executive responsibility, but not always the authority afforded to executives. A 
great leader almost always has great management skills. Conversely, manage- 
ment can be delivered without any discernable leadership skills. A product man- 
ager may be a good or bad leader, but a good product leader must be a good 
product manager too. 


Successful product design and development relies on strong product leadership. 
Organizations are using combinations of internal teams and agency partners to 
design and develop world-class products. Managing human beings and navigat- 
ing complex product roadmaps is no easy task. In fact it’s downright rare to find 
a product leader that can steward a product from concept to launch without some 
major hiccups. So, why do some product leaders succeed while others don’t? 
Through our decades of work in the product design and development space, we 
have learned what it takes to be a great leader. We've had the privilege of working 
with dozens of these exceptional leaders, and this book captures their 
approaches, styles, insights, and techniques to provide a guide for other product 
managers hoping to emulate their success. 


Many of the insights in this book will fit the broader definition of good leader- 
ship. That is unavoidable. Product leadership is not an island, and much of what 
you read here may be relevant to other leadership roles. However, there are also 
some very specific challenges to product leadership that similar leadership roles 
won't face. This book tries to highlight those challenges while being true to the 
idea that great leaders share universal skills and characteristics. 
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Who Needs This Book and Why 


For the uninitiated it might seem like product leaders are a relatively new partici- 
pant in the jungle of software product design and development. The truth is that 
they have quietly been making digital organizations successful for decades. What 
is new is the popularity of the product leader and the attention their work is 
attracting. We’ve seen product leadership in many forms over the years, but not 
until recently has the role of product leader become recognized in the realm of 
digital products. This leadership role is sometimes different from the product 
manager role. Leaders do not always manage others, and often their contribution 
looks decidedly like other executive jobs—guiding the broader organization along 
a path, not focused on oversight or group tasks. Leaders may not have a team to 
manage. In some cases they may even operate as individual contributors. As in 
executive leadership, the best product leaders come from a wide range of back- 
grounds and are forged in their environment, learning on the job and through 
the experience of their company and the market. 


We feel that there are real challenges ahead for product leaders, the most press- 
ing one being that of identity. As we’ve mentioned, leadership is not the same as 
management. In the current product environment, we need better leaders, not 
just better managers. This is true of the product roles too. We have found that 
there is too much emphasis on creating, training, and hiring product managers 
and not enough on product leadership. This is apparent in the significant 
amount of literature and commentary on the rise of the product manager, with 
very little attention given to the leadership role. Technical product roles are well 
described and documented, while leadership roles in product organizations 
remain fuzzy and ill defined. The purpose of this book is to clarify this ambiguity 
and expose the characteristics of great product leadership. 


This ambiguity has not always existed. Before software was ubiquitous, product 
leadership was the domain of technical people. Engineers and programmers 
made the core of the software products, so it made sense that they should man- 
age the product teams. As software has become less of a reason for companies to 
exist and increasingly a platform for experiences, the rise of product managers 
from backgrounds in marketing, business, and design is more common. We 
don’t believe the ideal product manager has a specific background or education, 
but we do see similarities in successful product leaders. Domain-specific skills 
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aside, product leadership is more about leading people and less about pushing 
pixels, writing code, or administering project schedules. 


This book has been written for the product leader role in context, not just the per- 
son who carries the title. The leader never operates in a vacuum, so this book is 
for the product leader, their team, and even the people who hire them. 


This book describes how the product leader can deliver the success the product 
organization seeks, whether by crafting a freshly minted product out of thin air 
or by innovating a decade-old suite. The insights written here are based on our 
experience working with hundreds of software products, and interviews with doz- 
ens of the world’s best product leaders, at product organizations such as Adobe, 
YouTube, Uber, Google, Airbnb, Basecamp, Zipcar, Intuit, Intercom, Sonos, 
Drift, Rue La La, Transferwise, Upthere, Localytics, Cinch Financial, and Pro- 
ductPlan. It includes insights not just from us but from seasoned product experts 
like Ken Norton, Marty Cagan, Mina Radhakrishnan, David Cancel, Vanessa Fer- 
ranto, Josh Porter, Janna Bastow, Josh Brewer, Melissa Perri, and Colin Kennedy, 
and from product partners like GV (previously Google Ventures), Mind the Prod- 
uct, Pluralsight, Fresh Tilled Soil, Clearleft, and Rocket Insight. 


By categorizing the book into the broad stages of a company’s growth and sepa- 
rating the parts into insights for managers, teams, organizations, and customers, 
we've made the knowledge as accessible as possible. Whether just starting out or 
midway through their career, product leaders will be able to flip to the part that’s 
most relevant to their needs and return to the book when they encounter new 
challenges. 


This book is not a read-once handbook to be followed to the letter. Neither is it a 
step-by-step guide on how to be a product manager. It’s a framework for product 
leaders to give their challenges some guardrails and avoid the mistakes made by 
the many that have come before. These lessons are going to be relevant at differ- 
ent stages of a product leader’s career—whether they are working at a small 
startup or leading the product division at an international corporation—and at 
each point of an organization’s evolution. The stories can be read, internalized, 
and applied in the way most relevant to the situation, the organization’s needs, 
and the level of product maturity. Topics can be revisited when circumstances 
change, such as after a move to a new job. 
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There will certainly be actionable insights that can be applied today, but not 
everything will be useful right here and now. However, the insights here are 
largely timeless and trend or technology agnostic. These are skills leaders can use 
today and in the future, regardless of platform, market, or job title. 


ALL THE RESPONSIBILITY WITH NONE OF THE AUTHORITY? 


For many product leaders, work life is a constant tension between delivering 
value to one group and telling another they can’t have what they want. Shipping 
product, and its associated value, is the reason these product leaders get up and 
go to work. This might sound straightforward, but it isn’t without its challenges 
—challenges that typically aren’t just functional, but conceptual too. It’s this sub- 
tlety that means product leaders are not always product managers. In fact, true 
product leaders may not have traditional management roles. We’ll explore this 
difference between managers’ and leaders’ work throughout the book. 


Product leaders work under the pressure of delivering value while managing the 
expectations of multiple stakeholders. Although the analogy “CEO of the prod- 
uct” might not be ideal, it expresses the high level of accountability associated 
with the product leader position. But despite having much of the responsibility of 
a C-level executive, product leaders lack the absolute authority of a CEO. It is 
worth mentioning that there are notable exceptions in early-stage companies, 
where the product leader might also be the CEO, but the takeaway here is that 
leadership isn’t always about authority. In fact, in the modern consensus-driven 
workplace, the assumption of authority isn’t guaranteed for true leaders. As Matt 
Asay, VP of Mobile for Adobe Marketing Cloud, notes, “I don’t have actual 
authority to demand that people do certain things. I can influence and persuade, 
but I can’t walk into a room and threaten my people to do something or they are 
fired.” Authoritarian leadership is going the way of the dodo. As Asay points out, 
great product leaders lead by influence and example. 


Authority often comes with the job. Product leaders do have authority over cer- 
tain aspects of the product delivery cycle, but they won’t necessarily have author- 
ity over individuals or teams in the same way that a traditional manager might. 
Despite the fact that what product leaders do each day is critical to the success of 
their organizations, there are insufficient examples of best practices and market- 
tested knowledge. This is partly because every company has a different set of 
product challenges, but also because each maintains a unique culture. However, 
there are best practices and universal truths that apply to all product organiza- 
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tions. With the help of our experts’ perspectives and decades of industry experi- 
ence, this book attempts to start filling those gaps with insights that are useful to 
all product leaders. 


Apart from identifying best practices for product leaders, the book’s aim is to 
address leadership in a broad context. No leader operates in a vacuum, and align- 
ing their activities with the greater organization is essential for success. Depend- 
ing on the maturity of the organization, the work that product professionals do 
isn’t always in agreement with the company vision, the customer’s needs, and 
the team’s abilities. Getting everyone on the same page is key to successful lead- 
ership. This book is about understanding the challenges and the disconnects, 
and defining a way for the product professionals to get the insights and knowl- 
edge they need to be better positioned to deliver the best value for the business. 


Product leadership starts with: 


e Understanding what makes product leadership unique and different from 
marketing, operations, engineering, and other domains, and how it works 
with them. 


e Knowing your organization’s unique value and delivering on that value. 


e Connecting the product and company value together to ensure consis- 
tency. 


e Executing on that value to the customer and securing your place in the 
market. 


e Determining what type of product management and leadership your orga- 
nization needs at what stage of the business growth and maturity, and 
then recruiting, hiring, and training for that specific skill set. 


e Learning how to build the right team for your organization and then 
putting in place the process to ensure that team is nurtured and sup- 
ported. 


e Implementing a process that works for your organization. Not all compa- 
nies need the same process. 


e Learning how to appeal to your stakeholders and wider organization so you 
can build support for your work. 
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e Learning how to get your product team aligned with the company mission, 
vision, and values. 


e Measuring and evaluating the success of the team’s work. 


e Establishing a product culture that embraces autonomy with accountabil- 
ity. 


WHAT MAKES PRODUCT LEADERSHIP UNIQUE? 


It’s important to understand why product leadership is different from traditional 
marketing, operations, engineering, and other domains, and how it works with 
them. As we've said, leadership is not the same as management. They might 
overlap, but leadership roles differ significantly from traditional management 
roles. Individuals can be leaders. Leaders may not have any direct reports. Man- 
agers, by definition, will have management responsibilities, which means they 
have a team to manage. This difference is overlooked by many organizations, and 
it’s a problem. 


Product leaders also need business chops. They are required to deliver solutions 
that address the needs of the user and the needs of the company. That intersec- 
tion is defined by all the elements of the business. Understanding the financial, 
marketing, operational, and even the legal and regulatory environment the prod- 
uct lives in will be part of the product leader’s remit. It is definitely not a require- 
ment for product leaders to have a degree or experience in these areas, but they 
must speak the language and understand the priorities of each role. 


If approached correctly, the product leader position can be a source of truth and 
one of the purest forms of unbiased knowledge transfer for an organization. 
Approached incorrectly, however, the role can be extremely problematic—argua- 
bly even fatal—for the organization. We have spent a fair amount of time in 
many organizations and have found a similar pattern for what bad leaders look 
like. Most have built-in confirmation bias, don’t rely heavily on data, and conjec- 
ture repeatedly. A toxic leader has widespread effects. Teams begin to pick up 
many of these traits, and long before you know it, the organization is in a pretty 
bad way. 


Product management and product leadership are unique in an organization 
because the role touches so many parts of the business. Whereas some opera- 
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tions can operate successfully with limited interactions with other divisions or 
teams, product is tightly bound to all aspects of a business. It follows, then, that 
successful product leaders will be those that have a holistic approach and are con- 
nected to every aspect of the business that supports the product. According to 
Jim Semick, CEO and cofounder of ProductPlan, a tool for developing product 
roadmaps and delivery schedules, “The problem is that the product is not simply 
a set of features; the product is the way you talk about the product, it’s the way 
that you acquire customers, the sales process that you go through to actually 
close a customer, the experience that someone has when they’re going through 
that process. That’s all part of the product, at least in the customer’s mind.” 


Semick’s list of responsibilities emphasizes the complexity of the role, and the 
broad impact product leaders can have, but also underlines their lack of author- 
ity. Knowing which hat to wear is partly a matter of where you are in the product 
or business’s life cycle. Understanding the best approach at each stage can be the 
most demanding part of a fast-growing organization. A great product leader, cor- 
rectly supported by the organization, can be the single source of truth about the 
success or failure of a product business. Without support from the organization, 
a product leader isn’t going to have the impact they seek. Developing that sup- 
port is a theme that we'll discuss throughout this book. 


THE IDEAL PRODUCT LEADERSHIP STYLE FOR YOUR PRODUCT STAGE 


Understanding what type of product management and leadership your organiza- 
tion is ready for will set your team up for success. In theory, the right leaders 
build the right teams, and that leads to the right results; but in reality, finding the 
right people can be hard—very hard. Their attitude, experience, skills, and ability 
to adapt will determine the success or failure of your product organization. Not 
everyone is cut out to be a leader. Not all leaders perform well at each stage of the 
business’s growth. The best enterprise product manager is unlikely to be the best 
startup leader, and vice versa. 


Ultimately, the job of the manager or leader is to get results through other peo- 
ple. If there’s one key takeaway from this book, it’s this: it is not about individual 
success, it’s about getting the best out of others. That is the leader’s responsibility. 
There are a lot of great books on how to be a more successful individual or a bet- 
ter human being, but this is not that kind of book. The focus here is about mak- 
ing the entire team look good. It’s about the results that you can create with and 
through others. 
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How This Book Is Organized 


The book is presented in three parts in order to make it easy to access the rele- 
vant insights for the current stage of an organization. Part | introduces the con- 
cepts of product leadership and identifies characteristics that are common across 
the wide range of product leadership roles and styles. It also considers which 
characteristics set leaders and their teams apart. Part II breaks the product envi- 
ronment into various stages. Lessons from leaders in organizations of different 
sizes and different levels of maturity make up the bulk of this part. Finally, 
Part III explores the challenges facing product leaders as they work with outside 
teams and resources. For simplicity of reference, the parts of the book have been 
titled with the common stages businesses go through: startup, emerging, or 
enterprise. These categories are referenced throughout the book with the 
acknowledgment that there are gray areas in how a company defines its stage. 
Yet despite any oversimplification, these categories are useful in that they allow 
product leaders and the people they work with to quickly identify what character- 
istics and strategies will have the biggest impact on their organizations, their 
teams, and their products. 


This book is organized so that product leaders can choose their own adventure. 
We've arranged the insights and advice by company stage and by proximity to the 
product leader. In other words, we’ve placed the product leader at the center of 
the radiating ripples of team, organization, and customer. This does not suggest 
that communication with customers should occur only via the proxies of team 
and organization, but rather that the product leader’s primary concern will be 
establishing a high-performance culture, process, and product by successfully 
developing the best possible team and communicating to the right organizational 
influencers to deliver coordinated value to the customer. By segmenting the 
advice by organizational stage, the product leader can ensure customers are get- 
ting the most relevant and appropriate guidance. 


Current and past product leaders provide insights and recommendations for how 
to lead a product team through the stages of growth, each of which may well 
require a different approach, different skills, and, in some cases, different types 
of people. For those leaders who remain with a team as it steps through these 
stages, some personal evolution may be required. Progressing from one stage to 
another depends on the ability to hold these different strategies in mind while 
developing stage-appropriate leadership skills. 
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It’s important to emphasize that it’s very rare for a product leader to stay with an 
organization from startup to enterprise. It is more likely to see product leaders 
focus on their area of expertise with new or different projects and organizations. 
This book will hopefully provide a template that a product leader can apply in 
their circumstances. 


LEADING THROUGH GROWING PAINS 


In early-stage or startup environments, the product leader might also be the 
founder or one of the first employees. Freshly minted companies don’t have a 
robust product team, so the style of leadership is appropriately scrappy. The prod- 
uct leader still bears responsibility for painting a clear picture of the future while 
maintaining a firm grasp on the current reality. “We’ve talked about what our 
end state looks like, which of these teams will be working on their own, deciding 
what they work on directly with customers,” says David Cancel, Head of Product, 
CEO, and cofounder of Drift, of the current state of his startup and their journey 
toward achieving their future vision. “At this stage, we’re not there yet. We’re in 
the progression to get there.” Cancel is a veteran of several startups and by his 
own evaluation feels most comfortable at this early stage of a product business 
life cycle. “This is the little adjustment you have to make when you go back to 
early stage or the free customer stage. If you’re used to a product design and sys- 
tems that depend on the customer to work, then how do they work when you 
have no customers?” 


These are the types of questions this book aims to answer. This tension between 
the ideal state and the current state is a consistent theme regardless of product or 
organization maturity. Identifying which stage you’re in is half the battle. The 
other half is seamlessly transitioning across these virtual boundaries without 
upsetting the delivery of value to the customer. 


Through each stage there will be hurdles and frustrations. This is normal. There 
is no problem-free option in growing a successful product business, so we sug- 
gest you accept the struggle. Or, as endurance athletes say, “Embrace the suck.” 
This does not mean ignore bad things or sweep problems under the rug; rather, 
it encourages an understanding of how hard you're willing to work in order to be 
successful. What difficulties are you willing to confront to find meaningful 
rewards? Will you be willing to have the inevitable hard conversations? No worth- 
while journey is without challenges, and it’s essential that product leaders ask 
these questions of themselves and their team. 
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Leaders like David Cancel epitomize this desire to ask the hard questions and to 
embrace the suck. His leadership style is perfectly suited for the ambiguity of 
early-stage companies, and he accepts that. Accepting where you fit in helps to 
provide direction. It’s also useful to learn from those who’ve had to overcome 
similar frustrations and build on one another’s success. This book includes the 
hard-won advice of leaders who have found their path and who can share their 
stories and recommendations. Cancel, for example, describes the subtleties of 
early-stage product leadership and how it differs from later-stage businesses: “In 
the case of the early-stage business, as leaders, we had to make some hypotheses. 
We had to play the customer a little to get a bootstrapped system. Then, as soon 
as things were ready, we would get in beta users, and then daily users would be 
the proxy for customers.” These transitions all require the product manager to 
adopt an evolving style of leadership. Cancel believes that the product managers 
will transition from being proxies for customers (and for their own yet-to-be- 
hired teams) to guardians of the vision, so the authority can be returned to the 
team: “Now we have real customers, and we’re focused on getting more diversity 
in customers. So, little by little, as we get whatever critical volume means to our 
business, then we can stop, take our hands off things, and let the team start to 
run themselves.” This book is filled with similar product leader insights. We 
encourage you to read through each part to understand what these stages and 
transitions look like. 


LEARN HOW TO BUILD AND TRAIN A TEAM 


Each product team is as different as the business that supports it, just as each 
stage of a product organization brings different challenges. Finding, hiring, and 
training the right team for the specific demands of the work at each new stage 
must be done with these challenges in mind. Newer companies might not have 
the resources that mature organizations enjoy, but they do have agility and speed. 
Leveraging the environmental advantages to build the right team can have a 
major impact on the product success. Selecting people who mesh with those 
environmental factors is the job of the product leader. 


For example, the characteristics of an early-stage team will be more generalized 
than a mature team with highly specialized roles. “In a startup it’s essential that 
you hire people that are adaptable and can adjust very quickly,” says Product- 
Plan’s Jim Semick. “They need to act in an environment where there’s uncer- 
tainty. That’s the first thing. The second thing is you want to hire people that are 
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well rounded. People that can take on roles and expand beyond what you hired 
them to do.” Semick frequently referenced the importance of respect between 
team members, something that was reiterated by several product leaders. With so 
many tensions in an early-stage company, respect and empathy are part of creat- 
ing a space where the team can be productive and supportive. Nurturing a team 
that is respectful of team members’ needs and challenges goes a long way to get- 
ting a product out the door. 


As product teams transition to the emerging-growth stage of a company’s devel- 
opment, the challenges they face will change. Colin Kennedy, previously Product 
Manager for Boston-based Sonos, and now Product Manager at Upthere in San 
Francisco, describes how these rapidly growing teams are both constrained by 
resources and infused with new expectations. “We have this mid-size company 
level of resources, and it’s growing faster and faster as we’re accelerating our 
growth and development. However, each product team is still drawn on the char- 
ter of starting with a very small number of stakeholders from product manage- 
ment, design, and engineering in the key leadership roles.” Balancing growth 
with the limitations of resources and the startup “keep it lean” mentality is more 
art than science. Successful product leaders like Kennedy provide insights into 
how this need for balance can be achieved. Leadership is about helping people be 
their best. The skills that good leaders have to motivate, guide, and focus their 
teams is what sets them apart from others. 


Even the larger, more established companies put their teams at the center of the 
conversation. “I work day to day in teams,” says Jay Rivera at Intuit’s QuickBase. 
“So cross-functional conversations, whether it be a daily standup or our weekly 
program reviews, are all about ensuring that you have the right people on the bus 
and making sure you have the right people in the room at the same time. Cross- 
function involves product marketing, product development, ops, sales, product 
management, and HR.” This theme of having the right people present to make 
daily, weekly, or longer-term decisions is ubiquitous in successful product teams. 
As Rivera suggests, it’s about not just having the right team, but also ensuring 
that the team members come together to deal with the daily challenges. Efficient 
communication and decision making are key to great teams. Poor communica- 
tion between team members defeats the purpose of having great people. 
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IMPLEMENTING PROCESS AND PURPOSE-DRIVEN DIRECTION 


Process is the scaffolding for productivity. It’s not a replacement for smart people 
or customer-driven insights, but provides the framework in which those smart 
people can work as efficiently as possible. How much process is needed will be a 
function of the stage of the product and the experience of the team. For smaller, 
highly skilled teams, a very loosely defined process will suffice. For larger organi- 
zations that have a high churn rate among team members, a bulletproof frame- 
work for shipping product will be necessary. Independent teams—like product 
design agencies or corporate innovation groups—have more flexibility over the 
processes they employ, and in groups like this it’s possible to recruit highly talen- 
ted people rather than to force a certain process. “We’re going to hire smart peo- 
ple. They’ve got a whole toolkit of tools to use, but we’re not going to impose a 
structural process on them,” says Andy Budd, founder and Managing Director of 
Clearleft, one of the UK’s leading product design firms. “We trust them. We’re 
going to give them interesting problems, get out of the way, and let them solve 
the problem in the best way possible. And that means every single project is very 
different. And so we try and design the project and the process every single time. 
It’s unlikely we'll try to apply an identical process to every problem because every 
problem is going to be different.” Budd’s approach works well for smaller teams 
that have strong skills aligned around a trusting culture and are flipping from 
project to project. Larger teams that are deeply focused on a single product or 
project are likely to need more structure. 


The bottom line is that there simply is no right process or single methodology 
that covers every permutation of product, team, and market. In our experiences 
in organizations large and small, having the trifecta of smart people, a trusting 
culture, and a guiding framework can amplify results significantly. What is com- 
mon in high-performance teams is that they are cross-functional, collocated, and 
autonomous. 


The reality of the situation is that product leaders are dealing with humans, and 
just like the products they build, the interactions of these humans at scale 
become difficult to manage. Our shared philosophy is that success is more a 
function of an environment that creates and supports a great attitude than of ach- 
ieving perfection at every step of the process. Ultimately, whether your team is 
heavy or light on process, it’s crucial that everyone knows what’s expected and 
has a shared language to solve the inevitable problems. 
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Businesses, and the product organizations they support, are more successful 
when the purpose is clear. Meaningful work is better for everyone involved. 
Thought leaders on work culture, like Dan Pink and Simon Sinek, have given us 
blueprints for how prosperous organizations and teams orient themselves 
around purpose-driven work. Leaving this to chance is not a good strategy. Creat- 
ing or adopting processes that align with the “why” of an organization is the 
work of good product leaders. This book investigates how the top product leaders 
build teams and processes that focus on the big picture, and not on advancing 
their personal agendas. Joshua Porter, founder of Rocket Insights and previously 
Director of UX at HubSpot, reflects on building an environment that maintains a 
strong customer focus. “When we recruit, or when I recruit, [customer focus] is 
definitely a key trait. Something that goes along with that is a lack of ego on the 
part of the employee. We’re looking for people who are not focused on making a 
name for themselves through their own genius, but who are focused on creating 
a great product by doing well by the customer.” This attention on the customer 
isn’t a standard in product organizations, but it should be. Developing processes 
that remind teams of the customer and their needs is a big part of the leader’s 
role. 


Combining the right process for the product and business stage with a focused 
purpose gives the team the tools to be successful. It’s not enough to do just one 
or the other. Individuals on high-performing teams need to know why they are 
working so hard and what they can leverage to optimize their inputs. If your 
team doesn’t have a clearly articulated vision, then it’s hard for them to know 
how to make a difference. If the team understands the process, they’ll under- 
stand how to optimize results. 


UNDERSTAND HOW TO EVALUATE THE SUCCESS OF YOUR WORK 


Success is subjective, but how it’s measured is fairly objective. Having a clear set 
of metrics or criteria that define how your organization is meeting its goals is an 
essential part of the product leader’s role. For some leaders, it’ll be reframing 
business goals into measurable metrics like customer acquisition, net promoter 
score, and lifetime value. For others, especially those product managers manag- 
ing complex or mature products, their metrics might be very granular. Ultimately 
all metrics should connect to how the product delivers on its value proposition, as 
David Cancel of Drift affirms: “All of our metrics are geared on the customer, 
whether that’s usage or activation. Qualitative stuff is actually more important: 
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what we’re hearing from customers, what they’re actually saying. We talk to them 
every day.” 


The idea that measuring success and failure isn’t entirely a quantitative exercise 
came up several times in the interviews. True Ventures Design Partner Jeff Veen 
reaffirmed this trend. “I agree that in the sort of post—Agile/Lean world, I think 
we were overly quantitative. I just think we’re getting better at it rather than the 
pendulum swinging back to qualitative.” David Cancel supports the idea of quali- 
tative feedback guiding product decisions: “Any kind of qualitative feedback we 
have—written, or verbal, or visual—we take as understanding. Are we getting 
closer to solving the pain that our customer is having? And then are we starting 
to do that at scale? And then are we discovering new pains? Then when we invest 
in that new pain, are we seeing the kind of usage that we think is normal? These 
might initially be wrong because the use case might be different. And if we’re 
wrong, what is the right usage for this thing? We’re constantly looking at all 
these things at a customer level, at a cohort level, a feature level, and all levels, a 
plan-side level, at a buyer level, or a user level, all these different ways. And all 
the teams are measured against those customer goals.” 


Getting the balance right between qualitative and quantitative, it turns out, is the 
key to unlocking true customer insight. This cannot be emphasized enough. Nei- 
ther one is more important than the other, and embracing both is the answer. 
Teams that tend to be more metrics driven can struggle to make the leap to quali- 
tative research—driven methods. We’ve heard it argued in our own teams and in 
our book interviews that getting feedback from customers can be too much work 
or takes too much time. The solution is to reframe this work: qualitative research 
is an investment in future savings and value. Creating the practice and honing 
those skills will reduce the possibility of future failure. Doing the work upfront 
can prove immensely valuable, and the track record shows that early diligence 
reveals a better work product. Shipping, then measuring your impact, takes time 
and effort to get right as an individual and as a team. 


We're going to start with what makes a good product leader. We will also explore 
how they structure, guide, and mentor their teams to get the optimal results. 
Every team has its nuances and unique characteristics. The aim of the next part is 
to identify what common patterns appear in all successful teams. We won’t be 
discussing specific outputs, as these differ for each team, but we will discuss out- 
comes. 
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The Product Leader 


This part of the book focuses on what makes a product leader different and how 
they can achieve success. To grasp the significance of the role, we provide a his- 
tory of product management and discuss how it'll continue to evolve. We’ll peel 
back the layers on how the product leader operates in the larger organization to 
see how the leader’s work impacts the big picture. For product leaders, this part 
provides details on what themes and patterns represent the most successful lead- 
ers and how to attain those characteristics. For those tasked with hiring or devel- 
oping product leaders, we expose the characteristics to look for and nurture. 


Part I is divided into several chapters covering what product management is, why 
it’s so relevant today, being a great product leader, and whether there’s a formula 
for success. These chapters will set the stage for how product leadership lives 
inside the universe of product creation and how the leader influences those out- 
comes. 


What Is Product 
Management? 
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Before we can delve into what it means to be a product leader, it’s useful to clarify 
what we mean by product management itself, as it is a constantly evolving role. 
As we've already mentioned, product leadership and product management are 
not the same thing, but they are inextricably linked. An understanding of what 
product management is and is not will help contextualize the product leadership 
conversation. 


As Marty Cagan, Founding Partner of Silicon Valley Product Group and a 30-year 
veteran of product management, puts it, “The job of a product manager is to dis- 
cover a product that is valuable, usable, and feasible.” Similarly, coauthor Martin 
Eriksson, in his oft-quoted definition of product management, calls it the inter- 
section between business, user experience, and technology (see Figure 1-1; only a 
product manager would define themselves in a Venn diagram!). A good product 
manager must be experienced in at least one, passionate’ about all three, and 
conversant with practitioners of all three. 


UX TECH 


ai 


BUSINESS 


YOU ARE HERE 


Figure 1-1. Product management has been called the intersection between business, technology, 
and user experience (source: Martin Eriksson, 2011). 


Business 
Product management is above all else a business function, focused on max- 
imizing business value from a product. Product managers should be 





1 The word passion has become popular to describe people's connection to their work, but it isn’t the best 
descriptor. Being passionate does not mean having a purely emotional relationship with the subject. It’s 
also possible, and very often a requirement, to be dispassionate in the day-to-day management of the 
work while still remaining engaged and enthusiastic. 
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primarily focused on optimizing a product to achieve business goals while 
maximizing return on investment. 


User experience (UX) 

Perhaps most importantly, the product manager is the voice of the cus- 
tomer inside the business, and thus must be passionate about customers 
and the specific problems they’re trying to solve. This doesn’t mean the 
product manager should become a full-time researcher or a full-time 
designer, but they do need to make time for this important work. Getting 
out to talk to customers, testing the product, and getting feedback first- 
hand, as well as working closely with internal and external UX designers 
and researchers, are all part of this process. 


Technology 

There’s no point in defining what to build if you don’t know how it will get 
built. This doesn’t mean a product manager needs to be able to code, but 
understanding the technology stack—and most importantly, the level of 
effort involved—is crucial to making the right decisions. This is key in an 
Agile world where product managers spend more time with the develop- 
ment team than with anyone else inside the business, and need a shared 
language and understanding with their engineers. 


Other functions, like team development, marketing, and strategic planning, play 
a part too, but business, UX, and technology form the core of what product man- 
agers do every day. 


The Product Management Role 


Earlier we said that good managers are not necessarily good leaders. Good lead- 
ers, however, must be good managers, so in this section we will discuss the role 
of product manager and how it overlaps the role of product leader. 


Why does a product manager need skills in areas like business, UX, and technol- 
ogy? Primarily because the role itself is incredibly broad and varied. Nilan Peiris, 
VP of Product and Growth at TransferWise, says that product managers need to 
“do whatever needs to be done.” Tanya Cordrey, former Chief Digital Officer at 
the Guardian, adds, “One of the really fantastic things about product manage- 
ment, but also one of the real stresses of it, is that it is a very broad role. You have 
to be able to be really good at strategy, be inspirational, and understand the long- 


6 | PRODUCT LEADERSHIP 


term picture. At the same time, you have to be really good at the operational side 
and making things happen.” 


This starts with setting a vision for the product. The product manager should 
research their market, their customer, and the problem the customer is trying to 
solve. They have to assimilate huge amounts of information—including qualita- 
tive feedback from customers, quantitative data from analytics tools and statis- 
tics, research reports, and market trends, to name but a few. They need to know 
everything that can be known and then mix all that information with a healthy 
dose of creativity to define a vision for their product. 


Once the vision is in place, the product manager must spread the word through- 
out their business. They have to believe in the product and get almost evangelical 
about the utopia that the product vision represents. If they can’t get excited about 
it, then it’s possible they are not invested in the vision. In extreme situations this 
might mean they are in the wrong job or the product/vision match is not clear 
enough. Driving the vision forward is the first area where management and lead- 
ership overlap. It is a leadership job in the sense of ownership and guidance and 
a management job in the sense that it requires a system to communicate and 
reinforce the path on a daily basis. The team must both witness the leader’s 
vision and understand the manager’s implementation. The success of a product 
manager—and subsequently that of their product—relies on every team mem- 
ber, from sales to development, understanding the vision and becoming at least a 
little bit passionate about it. 


The product manager must then work toward building an actionable, strategic 
plan—a roadmap of incremental improvements, problem validation, and iterative 
design and development that takes the product step by faltering step closer to the 
final vision. This is when the hard work of preaching the product vision pays off 
and, driven by the product manager, the whole team throws itself into coming up 
with better designs, better code, and better solutions to the customer’s problem. 


At this stage, the process gets really detail oriented, as the product manager 
works day in, day out with the development team as a product owner. The man- 
ager is constantly defining and iterating the product as it evolves, solving prob- 
lems as they pop up, and closely managing scope so the product goes to market 
on time and on budget. 
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When the product is finally out in the market, the product manager should be 
spending their time poring over data and talking to customers face to face about 
the product to discover how they use it. Did it solve the right problem? Do the 
customers understand the product’s value? Will they pay for the product? Then 
the product manager goes back and does it all over again. 


When done optimally, this is not a waterfall process. There is too much to be 
gained from iterating in short cycles. In larger product organizations with 
mature product lines, the product managers and leaders are probably not doing 
these things step by step for just one product or feature. They’re doing this for a 
dozen products or features at any one time, all at different stages in their life 
cycle, switching from strategy to tactics as needed. 


Ellen Chisa, VP of Product at Lola, underlines this context switching: “A product 
manager is continuously going back and forth between the 10,000-feet view and 
the 2-inch view.” 


Mina Radhakrishnan, the first Head of Product at Uber, says, “A lot of people say 
the product manager is like the CEO or the captain of the ship. I don’t really 
think of it that way because when you describe things like that, it makes it seem 
as though you’re making the decisions, or you’re driving how everything works 
together. To me the product manager is really the person who works with every- 
body else to define and say: ‘This is how this thing should work, and this is why it 
should work in that way.” 


“Product management is the glue that holds together all the various functions 
and roles across a company that speaks different languages,” adds Ken Norton, 
Product Partner at GV (previously Google Ventures). “It’s like the universal com- 
municator in Star Trek—a hub of communication between all these different 
groups. A product isn’t going to be successful without that glue holding those 
teams together.” This underscores the greatest challenge for product managers— 
that the job is not just about the hard skills outlined earlier, but more about the 
soft skills of persuasion, negotiation, storytelling, vision setting, and communica- 
tion. 


Great product leaders need to present and communicate their ideas to others in 
clear, concise ways. These often-overlooked soft skills are critical for any leader 
but even more so for a product leader. In fact, as entrepreneur and best-selling 
author Seth Godin points out, calling them “soft” skills undermines their impor- 
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tance: “Let’s call them real skills, not soft. Yes, they’re interpersonal skills. Lead- 
ership skills. The skills of charisma and diligence and contribution. But these 
modifiers, while accurate, somehow edge them away from the vocational skills, 
the skills that we actually hire for, the skills we measure a graduate degree on. So 
let’s uncomfortably call them real skills instead.”? 


How Product Management Evolved 


While there’s no definitive history of the nebulous and fast-moving role of prod- 
uct manager, it’s useful to consider the roots of the role and how it has evolved. If 
nothing else, it helps to understand the organizational shift that has happened as 
capabilities and thinking around product management have changed, and to 
describe some of the underlying conflicts that still exist today. 


PRODUCT MANAGEMENT IS BORN 


Modern product management was conceived in 1931 with a memo written by 
Neil H. McElroy at Procter & Gamble. The memo was a justification for hiring 
more people—a familiar pain point for all leaders—but became a cornerstone in 
modern thinking about brand management and ultimately product manage- 
ment. 


What McElroy laid out in his 800-word memo? was a simple and concise descrip- 
tion of “Brand Men” and their absolute responsibility for a brand—from tracking 
sales to managing the product, advertising, and promotions. Uniquely, he out- 
lined that the way to do this was through thorough field testing and client inter- 
action. 


McElroy got his two hires. His ideas also led to the restructuring of P & G into a 
brand-centric organization and to the birth of the product manager in the FMCG 
(fast-moving consumer goods) field. McElroy later became Secretary of Defense 
and helped found NASA (proving that all product managers are destined for 
greatness), but he was also an advisor at Stanford, where he influenced two 
young entrepreneurs called Bill Hewlett and David Packard. 





2 Seth Godin, “Let's stop calling them ‘soft skills’”, Your Turn. 
3 N.H. McElroy, R.F. Rogen, “Marketing”. 
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Hewlett and Packard interpreted the Brand Man ethos as putting decision mak- 
ing as close as possible to the customer and making the product manager the 
voice of the customer within the company. The seminal 1995 book The Hewlett- 
Packard Way (HarperBusiness) credits this policy with sustaining Hewlett- 
Packard’s 50-year record of unbroken 20% year-on-year growth between 1943 
and 1993. Hewlett-Packard had many other firsts, including the introduction of 
the division structure, where each product group became a self-sustaining orga- 
nization responsible for developing, manufacturing, and marketing its products. 
Once a division became larger than 500 people, it was invariably split to keep it 
small. 


Meanwhile, in post-war Japan, shortages and cash-flow problems forced indus- 
tries to develop just-in-time manufacturing. Taiichi Ohno and Eiji Toyoda (the 
latter the nephew of Toyota’s founder and eventually the chief executive and 
chairman of Toyota Motors) took this idea and—over 30 years of continuous 
improvement—developed the Toyota Production System and the Toyota Way. 
They focused not just on eliminating waste in the production process but also on 
two important principles any modern product manager will recognize: kaizen, 
improving the business continuously while always driving for innovation and 
evolution, and genchi genbutsu, going to the source to find the facts to make cor- 
rect decisions. 


A great example of these two Toyota Production System principles is Toyota engi- 
neer Yuji Yokoya, who was given responsibility for engineering a new generation 
of the Toyota Sienna minivan for the North American market. He didn’t just 
pore over the data and feedback they had on the old model internally, or simply 
talk to existing customers—he drove a Sienna more than 53,000 miles across 
America, from Anchorage, Alaska, to the Mexican border and from Florida to 
California. What he learned led to significant improvements in the new model, 
and renewed sales success. 


Of course, when just-in-time manufacturing came to the West, Hewlett-Packard 
was one of the first to recognize its value and embrace it. Hewlett-Packard 
alumni brought this customer-centric, brand-vertical, and Lean manufacturing 
way of thinking with them to their future jobs, quickly permeating the growing 
Silicon Valley with the same ethos. From there product management spread into 
every hardware and software company to become the global and evolving role we 
recognize today. 
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PRODUCT MANAGEMENT COMES TO TECHNOLOGY 


The original product managers, and indeed the majority of product managers in 
FMCG today, were very much a part of the marketing function. They focused on 
understanding their customers’ needs and finding a way to fulfill those needs 


using the classic “four p’s” of marketing: the right product, in the right place, at 
the right price, using the right promotion. 


Their key metrics were sales and profits, but due to long lead times in the devel- 
opment and production of new products in FMCG, they focused on the final 
three p’s (place, price, and promotion), or Shimizu’s four c’s (commodity, cost, 
communication, and channel). Thus, product management in FMCG was largely 
a marketing role, concerned with getting the right mix of packaging, pricing, pro- 
motions, brand marketing, and so on, and leaving the development of the under- 
lying product to others. 


As the product management role moved into the tech world, however, this sepa- 
ration from the development and production of the product was untenable. Most 
of the new companies in the tech world were inventing whole new industries, 
and they couldn’t rely on just the packaging and pricing of a commodity to suc- 
ceed. This brought product development back to the center of the product man- 
agement role, which recognized that it was imperative not only to understand the 
customer and their needs, but also to align product development with them. 


This schism between marketing and product management is still felt in many 
tech organizations today, where both departments feel they own the customer 
and understand the marketplace. However, in most tech organizations, market- 
ing has evolved to be more about owning the brand and customer acquisition, 
while product owns the value proposition and development. 


PRODUCT MANAGEMENT GOES AGILE 


Originally, even in the tech industry, product development was a slow and labori- 
ous procedure that plodded along a waterfall path: first researching, followed by 
writing a massive product requirements document over several months, and 
then throwing that over the wall to engineering, only to get something com- 
pletely different out the other end several months later before starting the pro- 
cess all over again. 
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In 2001, 17 software engineers got together in a ski resort and wrote the Agile 
Manifesto,+ which built on work spanning back to the 1970s on lightweight alter- 
natives to the heavy-handed and process-oriented waterfall method of developing 
software. Though Agile and the Agile Manifesto are heavily associated with 

Scrum,’ Scrum was actually developed before the Manifesto alongside other 
methodologies—like DSDM (Dynamic Systems Development Method) and XP 
(eXtreme Programming)—that were trying to achieve the same goal. Kanban, 
another great method widely used in product development today, was imple- 
mented under Taiichi Ohno and Eiji Toyoda in the Toyota Production System as 
far back as 1953. 


Whatever the genesis, the Agile Manifesto brilliantly articulated the principles 
behind all these various methodologies and is still incredibly influential and val- 
uable today: 


We are uncovering better ways of developing software by doing it and 
helping others do it. Through this work we have come to value: 

+ Individuals and interactions over processes and tools 

+ Working software over comprehensive documentation 

+ Customer collaboration over contract negotiation 


« Responding to change over following a plan 


That is, while there is value in the items on the right, we value the items on 
the left more. 


The Agile Manifesto was a watershed moment in development process and thus 
greatly influenced product development. Not only did it liberate software engi- 
neers from being conveyor-belt coders expected to churn out exactly what was 
specified, no matter how mindless, but it also freed product management from 
focusing on deliverables like specifications, allowing them to focus on customer 
collaboration. 





4 Ward Cunningham, “Manifesto for Agile Software Development”. 


5 Scrum is an Agile software development model based on multiple small teams working in an intensive 
and interdependent manner. The term is named for the scrum (or scrummage) formation in rugby, which 
is used to restart the game after an event that causes play to stop, such as an infringement. 
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This focus shift was profound on many levels. Firstly, it changed the relationship 
between product management and engineering from adversarial to collaborative. 
Scrum invented the role of product owner, but Agile methods all embraced fre- 
quent and in-person communication between product management and engi- 
neering as the foremost way to find and build the best solution to a customer 
problem. 


Secondly, focusing on the customer eased the artificial separation between the 
research, specification, and development phases of a project. Although the gap 
has not been entirely eliminated, it’s been a positive step toward reducing the 
divisions. This moved elements of UX from being an afterthought to being a fun- 
damental part of the genesis of a product. That, in turn, played an integral role in 
the ongoing process of discovery and development. It’s clear that our industry’s 
transition to a fully integrated customer-focused process is not complete. Time 
will tell how deeply Agile will affect product leadership. 


Finally, these principles have permeated the business through the creation of 
Lean practices and the development of the Lean Startup and Lean Enterprise, 
which build on the previously mentioned Japanese kaizen tradition of continuous 
improvement and apply the Agile, iterative approach not just to product develop- 
ment, but to the business itself. New patterns are emerging, and it is exciting, 
encouraging, and engaging to see such strides being taken in our craft. 


PRODUCT MANAGEMENT TAKES A SEAT IN THE C-SUITE 


Until recently, product management was generally considered a part of the mar- 
keting or engineering function. It reported up through those hierarchies, was 
naturally aligned more with one or the other, and because of this ambiguity, 
inevitably became embroiled in conflicts of prioritization and areas of focus with 
other departments. 


These days, product management is increasingly a standalone function with a 
seat at the management table and a direct report to the CEO. It’s at this juncture 
that product management becomes product leadership. With a direct relation- 
ship with the CEO, or in some cases being the CEO themselves, product leaders 
own the thread that connects vision with implementation. This is critical because 
it aligns the product team directly with the business vision and goals, makes 
them internal as well as external evangelists of that vision, and gives them the 
independence necessary to make tough calls. 
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A frequent example of this is the struggle between sales and marketing over who 
owns the go-to-market pricing of a product. Recently we’ve seen a shift to send 
this critical decision to the product leader of the organization. They are the ones 
who can best represent the interests of the user and strive toward a profitable rev- 
enue expectation by selling the right solution at the right price to the right cus- 
tomer. “Product management needs to be at least a peer to engineering and 
marketing,” says GV’s Ken Norton. “It needs to report to the CEO; it needs to be 
directly accountable to the person running the company.” 


As coauthor and master manager Nate Walkingshaw asks in his Directed Discov- 
ery® process: “Are your product discovery and delivery teams empowered to 
change the company’s vision, strategy, culture, and processes?” This might be 
the most important question a product leader can ask, because if the answer is 
no, then the product group will be hamstrung from the start. The connection 
between product leadership and management becomes a question of how the 
management of a product informs the overall culture and leadership of the prod- 
uct organization. This brings its own challenges and opportunities, which is what 
this book is all about! 


What’s Next for Product Management? 


Good product management has become a sustainable competitive advantage, and 
continues to evolve. It can be argued that a company’s product and technology 
strategy has become the corporate strategy for many fast-paced, best-performing, 
and innovative companies in today’s market, who maintain a clear line of sight to 
a product and a user-driven strategy and culture. 


Product management continues to absorb parts of marketing, with many organi- 
zations making user acquisition activities a part of product, recognizing that 
good product is often the most cost-effective and fastest way to grow. It continues 
to take on elements of user experience, separating the user flows and experience 
from the visual design. It embraces fluid processes that adapt with what best fits 
the team, the product, and the market—whether it’s Scrum, Kanban, something 
else entirely, or a combination of all of the above. 





6 Nate Walkingshaw, “Part I: Building a People Platform for Continuous Change in Technology”. 
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Most importantly, product management has become more widely understood 
and owned within organizations. It has become a discipline in which you may be 
an engineer, a designer, a founder, or a product manager. All that matters is the 
focus on the product and how it serves your customers’ needs. It is our strong 
belief that the future of successful product management and leadership will be 
where product organizations focus on customer experience. It’s not about engi- 
neering, design, marketing, or unit economics as much as it is about truly solv- 
ing customer problems with those inputs. As product management veteran 
Melissa Perri, CEO of Produx Labs, says, “The value is that the feature actually 
solves the problem for the users. It’s an outcome that matters, not the output.” 


Product leaders are at the cusp of defining a new path forward, one where they 
can transform a company’s ability to build on a holistic foundation centered on 
the user. The best part is that companies built on these foundations will have 
endless staying power. Product success in these organizations doesn’t have a 
strong bias toward short-term business results, but rather toward the best inter- 
est of the user and the health of the ecosystem it supports. This knowledge can 
help a company avoid establishing a foundation on quick wins that may not be 
sustainable. We acknowledge that areas of management like operations, sales, 
and marketing are essential, but for the product organization, these things 
should exist in support of the user’s experience, not in spite of it. All of those 
areas underpin the effectiveness of the product and are absolutely necessary, but 
product management, user experience, design, and product engineering actually 
move the needle toward the ever-evolving product market fit. A powerful industry 
adage is that the day you ship, history has been made. In other words, you are 
history the moment the product is out the door. That moment is nothing more 
than a signal to evolve and improve. Building a product management organiza- 
tion that can do this well can set the entire business up for success. 


2 


Why Is Product 
Leadership So 
Relevant? 
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The Product Leader’s Impact 


A product leader is ultimately responsible for the success or failure of a product 
and, by extension, the company itself. The impact of that cannot be underestima- 
ted. According to Ken Norton, product leaders are “the implementers of the com- 
pany vision,” always pushing the company forward by “focusing on what is most 
important to the company—what do we want to accomplish as a business and 
what do we need to do to get there?” Norton’s time at GV (previously Google Ven- 
tures) convinced him of the importance of product leadership. He believes that 
product leaders should have a vision for the product and where it should be in a 
year, in 5 years, and in 10 years—and then articulate this vision to the rest of the 
leadership team and to the wider organization. Creating a product vision and 
crafting a plan to get there is as relevant as you can get to the organization’s 
success. 


As Ben Horowitz of the successful venture capital firm Andreessen-Horowitz put 
it 15 years ago while he was a Product Manager at Netscape: “A good product 
manager acts like and is viewed as CEO of the product. Good product managers 
have a realistic vision of what success of their product means, and they ensure 
that this vision becomes reality—whatever it takes. Good product managers are 
viewed by the entire product team as the leader of the product.” As we've 
acknowledged, the CEO analogy is problematic, but successful product leaders 
often look and sound like CEOs. Understanding that product managers are lead- 
ers and not just managers is the cornerstone of this book. Forgive us if we repeat 
this point throughout the book. It’s an idea worth reinforcing. 


THE EVOLVING ORGANIZATION 


The product team is in the unique position of trying to achieve an outsize 
impact, while having almost no authority over the teams that build, market, sup- 
port, and sell the product. “When you’re a product manager,” says Norton, 
“you're generally not the boss. You need to gain authority through your actions 
and your leadership skills, not your role.” This is very different from previous 
generations, when the manager held authority over the team and decisions by 
virtue of the title. That era has passed and a new approach to management has 
emerged. As Norton says, management is now earned through positive behavior. 


Product leaders should never assume that their title qualifies them to lead by the 
inferred authority of the role alone. “Responsible and accountable does mean 
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that we have teams that are actually accountable and responsible, and my job is to 
make sure they want to turn up to work,” says Nilan Peiris, VP of Product and 
Growth at TransferWise. “They work as one on a team, and that’s due to upfront 
thinking about hiring and about culture and about leadership within teams.” 
This cooperation doesn’t happen by accident. Product managers and leaders are 
expected to take an active role in building culture and leading their teams 
through the mundane day-to-day activities, not just the high-level strategies and 
vision. 


Viewing product teams as peers to the other departments “sets up a healthy ten- 
sion between engineering, product, and marketing, and the different ways those 
departments think. This is healthy because it allows product management to syn- 
thesize all these alternative views into the optimum decision for the product and 
the company,” continues Norton. Balancing the feedback and friction that comes 
from other teams and external sources is part of the job. An evolving organiza- 
tion realizes that eliminating friction isn’t the mandate—it’s understanding what 
insights might result from that friction. Maintaining this friction while prevent- 
ing chaos is something Steve Selzer speaks passionately about. As the Experience 
Design Manager at Airbnb, he is referring specifically to the friction that results 
from a poorly designed UX, but his insights are relevant to all aspects of product. 
“It’s generally a good thing to remove friction, but we need to retain the friction 
that helps us grow, that helps us navigate change and become resilient,” Selzer 
says. As is the case with so many things in product creation, the rules that apply 
to successful product design also apply to successful product team leadership. 


THE TEAM 


Without a team, the role of the product leader would not exist. The successful 
leader is reflected in the success of their team; and likewise, a poor leader is 
revealed by the failures of their team. It has been suggested that if product lead- 
ers were paid by the effectiveness of their teams, we’d have more successful prod- 
ucts. How the team is recruited, developed, and guided is probably one of the 
most important elements of the product leader’s role. It is also, without a doubt, 
the hardest part of the job. “Every team deals with personalities,” says David Can- 
cel, CEO and cofounder of Drift. “Sales and marketing have a certain set of per- 
sonalities they deal with from a leadership standpoint. But product is very 
different and very interesting. For one thing, we’re in a market where product 
managers, engineers, and designers have all the options in the world, so why 
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should they work on your product versus others?” Cancel, who has led product 
teams at Performable and HubSpot and was CTO of Compete (acquired by 
WPP), has an unconventional view on product leadership, “that may not be the 
same in other teams, where leadership can be very top-down and very by the 
book.” 


Product leaders have more relevance because they are increasingly the people 
responsible for connecting the dots between the executive vision and the practical 
work on the ground. Bryan Dunn, Senior Director of Product Management at 
Localytics, talks about the early days at his company. “When the company was 
still small enough, our CEO and COO were making a lot of the product deci- 
sions, but as the company grew this didn’t scale very well. They would make 
some decisions but couldn’t get into the details enough to understand all the 
nuances and tradeoffs of those decisions. They might’ve seen the potential value, 
but in terms of feasibility and usability, they didn’t have enough depth or time to 
work through these things with customers in order to give the engineering team 
guidance about what the market needed.” 


A product leader needs to balance the triumvirate of viability, feasibility, and usa- 
bility. To do this, they look to the executive to handle the viability aspect and then 
translate that into what’s feasible and usable. The CEO should be setting the gen- 
eral direction for the company. For some early-stage companies, the CEO will 
also be occupied with raising money, adding senior team members, and a dozen 
other things. As Dunn says, “I was spending so much time with customers doing 
the detail-oriented work that a product manager does, that I started to have my 
own opinions about what we should be building.” Dunn’s observation shows that 
it is often the people closest to the customer who are best suited to make product 
decisions. This fact means that product leaders are also best suited to shape the 
direction of the product. Product leaders have firsthand insight into the customer 
experience. This insight might not be available or top of mind with all senior 
executives in the organization. The product leader must have the authority to lead 
the organization’s product direction. 


THE MAKERS 


Managing the flow of information and directing the organization as an advocate 
of the customer are important aspects of being a product manager. Leading the 
internal team is an essential part of the job. “In product teams, you have to deal 
with makers,” says Cancel. “Makers are different, sometimes difficult or weird. 
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In a product team we are all makers, and so the personality challenges that you 
deal with—how you build a team, how you align personalities within that team, 
and then how you motivate them—are very different.” Makers need uninterrup- 
ted time to create stuff and solve problems. Some process ceremonies can inter- 
fere with this focused time. All managers and leaders should be judged by their 
team’s outputs, and product leaders are no different. If you’re managing a team 
of makers, your day will be judged by how well you protected them from distrac- 
tions and what they were able to make. This dimension further distinguishes 
product leaders from old-school management. No longer are they barking orders 
at subordinates; rather, they're empathetically motivating creative personalities 
toward mutually rewarding goals. They create safe mental and physical places for 
makers and problem solvers to work, and make the team the heroes. This means 
the leader is also an advocate, coach, guide, mentor, and cheerleader to the team. 
As one executive product leader told us, “When I was a Senior Engineering Man- 
ager, my job was all about technology and process; now I’m Chief Product Offi- 
cer, and my job is all about dealing with people and their emotions.” 


Challenges Specific to Product Leadership: More Than Just a Seat at 
the Table 


Product management and product leadership are not new roles. They are defi- 
nitely better understood and more visible than ever before, but they have been 
around for some time. We and many of our interviewees have been marketing, 
designing, and developing internet and web products since the late 1990s. Even 
then, product managers and product leaders were taking care of business. What’s 
improved is how the role has been integrated into the overall business conversa- 
tion. In the past, product managers were often line managers or functional lead- 
ers. We’re delighted that the current market expects to see those product leaders 
alongside the most senior people in the product organization. New titles and new 
visibility doesn’t always mean new responsibilities. Product still has to be 
shipped. However, getting a seat at the table has given product leaders the visibil- 
ity they need to express their priorities. The challenges may be similar, but now 
they’re getting the attention they need to be dealt with appropriately. 


In our conversations with product leaders we’ve heard that although they are 
clear about their value and role, it’s not always that obvious to others in the busi- 
ness. In the worst-case scenario, product leaders are often confused with more 
traditional senior roles like designers, experience designers, developers, engi- 
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neers, or marketers, and this is understandable. One thing that contributes to 
this confusion is that product leaders often wear several hats. This is particularly 
true of smaller companies and startups. In these young organizations a product 
leader might join as a lead UX designer, but go on to manage the full spectrum 
of product deliverables. We’re not advocating that product managers be forced to 
do several jobs, but it does happen. Related to this is that often great team leaders 
—not just great product leaders—jump in where needed. The best leaders have a 
ubiquitous and positive influence in their organizations, and this can make it 
seem as if the product manager or leader is all over the place. The reality is that 
they are doing what it takes to ship product and make it successful, and if you see 
a product leader doing this, it’s because they care. 


“For other leadership roles, you’re responsible for bringing a particular perspec- 
tive to the table: [the] best possible way we can do marketing, [the] best possible 
architectural decision, or [the] best option for our service team,” says Ellen Chisa, 
VP of Product at Lola. “From the product perspective, you can’t just say this 
would be the best thing for the product, because that’s about putting all of those 
pieces together. It’s a role where you synthesize and figure out with each of those 
leaders’ expertise how you can make the most effective strategy.” 


What Product Leadership Is Not 


A product leader is not the source of all the answers. In such a dynamic environ- 
ment it’s simply not possible to have all the answers. Product organizations are 
incredibly complicated places, and no single person can have every solution at 
their fingertips. Product leaders cannot memorize all the technical details of their 
job, and trying to would be a waste of time. Instead, a productive use of time is 
figuring out what the right questions are and where to get the answers to those 
questions. A culture where it’s OK for anyone on the team to say, “I don’t know, 
but I can find out,” nurtures responsibility and maturity, and is a far better strat- 
egy than pretending to be a human search engine. 


What Makes Product Leadership Strategic 


Product leadership “has a lot in common with all types of leadership roles, which 
is simply that your day-to-day work becomes less important than how you 
actually lead a team to accomplish something,” says Mina Radhakrishnan, the 
first Head of Product at Uber, who is now a mentor at 500 Startups while work- 
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ing on a new startup. That difference between how much you do and how much 
you enable others to do is a common factor across all leadership roles, whether 
it’s product leadership, marketing leadership, or engineering leadership. “The 
difference with product leadership is that it becomes especially important to 
focus on strategy and to really think about how all of the different elements come 
together with the overall company strategy. Essentially the product strategy is the 
company strategy,” she adds. Ultimately a product leader is responsible for the 
product strategy but can’t build anything by themselves and must lead engineer- 
ing, marketing, design, and other teams under the umbrella of the company 
strategy, all without the aforementioned authority. 


What Keeps Product Leaders Awake at Night 


In a recent survey, Mind the Product’ and Christian Bonilla, Product Manager 
and founder of UserMuse, asked product managers and leaders what challenges 
they faced. The results indicated that prioritizing roadmapping decisions without 
market research was by far the biggest, followed by being stretched too thin, deal- 
ing with executives, hiring and developing talent, and aligning strategy. 


PRIORITIZING IDEAS, FEATURES, AND PROJECTS 


It’s not surprising that prioritizing ideas or features rates high among the chal- 
lenges faced by product leaders. Any product manager knows that the most diffi- 
cult part of their job is determining what to spend time, money, and energy on. 
This is because it’s a deeply charged topic. These are not just ideas or features; 
they are people’s pet projects, and a lot of emotion is tied to them. 


In the Mind the Product survey, 49% of product managers said their foremost 
challenge is being able to conduct proper market research to validate whether the 
market truly needs what they’re building. When we look at the responses from 
enterprise software PMs, this figure jumps up to 62%. That means that almost 
two-thirds of enterprise product leaders are currently worrying about which 
projects are needed. If we extrapolate from this, an enterprise product leader will 
have to dedicate the necessary amount of their time to prioritizing projects and 
communicating to others the next product release. That’s a lot of tough conversa- 





1 Christian Bonilla, “The biggest challenge for product managers?” Mind the Product. 
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tions with a lot of unhappy people. Having to make tough decisions that might 
disappoint people sounds stressful, and it is. 


And that’s not all. In any organization, small or large, stakeholders also need to 
be dealt with. Often in senior positions, these people will impose their choices or 
opinions without the necessary data or understanding, a situation commonly 
known by the derogatory nickname HiPPO, for highest paid person’s opinion. As 
common as this term is, though, it doesn’t really give these unfortunate situa- 
tions the context they deserve. Senior people are rarely malicious, and referring 
to them as thoughtless animals only reinforces the stereotype. 


The reality is that stakeholders clouding decisions without evidence can derail 
even the most well-thought-out plans. Nobody likes it when high-level ideas are 
added to the roadmap as must-haves, especially when they are not backed up 
with validation. “The team just experienced another executive swoop and poop,” 
says Jared Spool, founder of User Interface Engineering? and cofounder of Cen- 
terCentre, likening these executive decisions to a seagull attack. “The executive 
swoops into the project and poops all over the team’s design, flying away as fast 
as they came, leaving carnage and rubble in their wake.” As humorous as this 
sounds, it’s also Spool’s hyperbole. Teams and their leaders are more often work- 
ing toward common goals and have no desire for anything ending in carnage and 
rubble. The absence of evidence is addressable without drama. 


To many product professionals, having their roadmap hijacked from time to time 
by other pressing issues is an unavoidable situation that must be tolerated. Tom 
Greever, author of O’Reilly’s Articulating Design Decisions, calls these hijacking 
decisions the CEO button, “an unusual or otherwise unexpected request from an 
executive to add a feature that completely destroys the balance of a project and 
undermines the very purpose of a designer’s existence.” We acknowledge that 
these interruptions can often be harmless, but if they continue unchecked, they 
will ultimately derail the product. Fortunately there is a solution, but it is not a 
quick fix. 


Prioritization can be polarizing because it’s often perceived as choosing one per- 
son’s ideas over another’s. When people have something personal invested in an 
idea or feature that’s on the chopping block, emotions can run high. The solution 





2 Check out the User Interface Engineering (UIE) home page. 
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is collaborating at several levels. It is the product leader’s job to connect with all 
the stakeholders and communicate to each of them why certain choices have to 
be made. It starts with developing a shared vision and purpose for the product. If 
the team doesn’t agree on the big picture, then they certainly won’t agree on a 
single feature. 


“As product managers it’s our job to make sure that the company is building the 
right product, but many (possibly a majority) of us don’t feel like we’re doing 
that,” says UserMuse’s Christian Bonilla. “Nearly all of the responses in this [pri- 
oritization] bucket expressed not having time to do market validation at all.” 
Bonilla reminds us all that it’s easy to get stuck on the treadmill and forget what 
the most valuable things are for product success. “It’s a little sobering when you 
think about how much time, money, and energy is being wasted building fea- 
tures that the market doesn’t want or need. It also tells me that the career devel- 
opment of many product leaders is slower than it ought to be.” This point 
highlights the importance of why product leaders need to be learning the art and 
science of prioritization. 


Mina Radhakrishnan adds, “A big part of product leadership is thinking about 
why are we doing this and using that to set the basis for saying, ‘No, we shouldn’t 
do that. It doesn’t make sense in the context of our larger strategy at this time.’ I 
think that’s really critical.” 


One way to avoid future disappointment is to create a testable prototype of the 
idea, feature, or interaction that is being planned. This can be done for most 
design features and interactions, and currently, the easiest way to do this is with 
the design sprint or Directed Discovery. Both of these approaches are based on 
the scientific method of developing a testable hypothesis and then running the 
appropriate testing cycles to generate results, providing immediate evidence 
either for or against the hypothesis. “When the team invites real users to try a 
prototype, they’re collecting data about the users’ needs, which provides a solid 
footing for the design,” says Jared Spool about design sprints. “When the execu- 
tive shows up, the team can present the data along with the design that emerged 





3 This last comment is more of an opportunity than a problem in our minds. Product leaders are ready to 
develop new skills and new approaches. Developing the right skills for the appropriate part of your career 
is a deliberate and necessary part of dealing with the prioritization problem. It's one of the reasons we 
wrote this book, and probably one of the reasons you're reading it. 
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from it. Demonstrating the data behind the design decisions reduces the poten- 
tial for negative influence the executive can assert, and smart executives will 
embrace the approach.” 


COLLABORATING EFFECTIVELY AND PRODUCTIVELY 


Collaborating is the way to get there, but it’s the outcome of this collaboration 
that’s the key insight. “Remember that collaboration is not consensus. Not every- 
one has to agree all the time. In fact, consensus rarely happens,” says C. Todd 
Lombardo, Chief Design Strategist at Fresh Tilled Soil and coauthor of the book 
Design Sprint (O’Reilly). “The roadmap prioritization approach is co-creation at its 
finest, which is akin to the Ikea effect: we love our Ikea furniture because we 
built it ourselves. The same applies here with product roadmapping. Involve the 
whole team and avoid sending off that Excel file via email; otherwise, you'll watch 
your email or Slack channel suddenly erupt in a fit of rage.” 


Lombardo, who has led hundreds of product design sessions, believes that the 
way to get over the collaboration hurdle is to share the details of each person’s 
perspective and opinions in a structured and repeatable way. Within the design 
sprint or Directed Discovery approaches are dozens of discrete exercises that 
team leaders can use to create collaborative sessions (see Figure 2-1 and 
Figure 2-2). For example, if the CEO wants to include a feature, then the product 
leader gets additional details from the CEO about why that feature needs to be 
included. This information or reasoning gets mapped against all the other fea- 
tures and perspectives so the entire team can see who wants what, and why. An 
idea that has no data, evidence, or testing behind it will not hold up against an 
idea that has the weight of research or testing behind it. Voting and ranking exer- 
cises add visibility and expose weak perspectives. Exposed to such close scrutiny, 
these executive decisions may be easier to defeat. This is not guaranteed, though, 
and product leaders should be prepared for some tough negotiating. Lombardo 
reminds us that “work is personal, so address that head-on with your team by 
including them in your roadmapping process.” 
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Figure 2-1. Gilbert Lee (center, standing) working with the Pluralsight product management and 
user experience team. At Pluralsight each product team is cross-functional and collocated. Every 
week the team gathers for two hours and works on each other’s experiences to arrive at the best 
outcomes for each experience. 


Q2 Team 





Figure 2-2. Matt Merrill of Pluralsight (standing, left) taking his turn to describe his team’s con- 
tinuous discovery and delivery work. Success means understanding each team’s work and the 
dependencies that may lie ahead so all can work and collaborate together. 


Product leaders should get trained in these disciplines and teach their teams how 
to conduct the collaborative sessions. Without these tools a product manager or 
leader can get stuck in a spiral of bad choices driven by executive will. “It’s a 
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bonus when the executive partakes in the Design Sprint directly,” says Spool. 
“Not only do they see the rigor of the process, they can contribute their knowl- 
edge and experience firsthand.” The benefit of any structured product collabora- 
tion process is that it neutralizes the politics in the organization and allows more 
junior voices to be heard. A level playing field lets the best ideas stand out, which 
makes the prioritization process infinitely easier. As Spool explains, “through 
each phase, the facilitator leads the activities using techniques designed to 
empower each participant, regardless of role power. Ideas and contributions 
from the sprint team’s lowest-ranking member are equal to that of any executive 
or other high-ranking members.” 


The insight for the leader is that using these process-driven solutions doesn’t 
exclude the need for leadership skills—specifically, leading with influence and 
relationship-building skills. Often, even after all that evidence and process work, 
the CEO still wants their request implemented. Tom Greever suggests that it’s 
not always about getting your way: “I would argue it has as much to do with earn- 
ing trust and building a relationship with that CEO than it is convincing them 
they are wrong.” 


Another key skill product leaders can bring to bear from their day jobs is using 
their user research experience to truly understand the CEO’s perspective and the 
reasoning behind the request. Understanding the why will help find common 
understanding and walk back to the real problem that needs solving. 


TRAINING AND DEVELOPING THE PRODUCT TEAM 


Teams don’t become teams by themselves. You may have the smartest people 
money can buy, but if they can’t work together, then you might as well not have 
them at all. The trick to creating a great product team is to think of them as the 
product. This is not an objectification but rather a thought exercise. After all, they 
are the product that creates the product. Without them, there is no product. 
Amazing teams make amazing products. Seen from this perspective, the task of 
how to hire, onboard, train, and develop them becomes another product design 
problem. The approach that successful leaders take to creating great product is 
the same approach they take to creating great product teams. 


The first step in product design is defining the purpose and the problem. In team 
creation, the principles of discovery and understanding apply too. Structured ses- 
sions where team members can discuss their biggest challenges and what they 
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understand as the team’s purpose will highlight any gaps. A timeboxed tool like 
design sprint can be used as a guide through this training. The specific approach 
you use doesn’t matter too much, as long as you are guiding the team through a 
process of understanding the problem and finding the solution. Ideally, the out- 
come should determine what problem the team is trying to solve, and with this 
insight, you can devise strategies for how the team can implement solutions. 


Getting the team on the same page is the underlying reason for this work and 
should not be rushed. Understanding the problems and the environment that’s 
contributing to them can take time. An hour on a Monday morning might not 
cut it, and some teams may need several sessions to come to an understanding of 
each other. Ongoing and consistent training should be built into the team’s 
weekly schedules. This might sound time-consuming, but itll save time and 
money in the long term if the team works productively and collaboratively toward 
a shared agenda. 


Individual growth plans for leaders and their teams are as important as team 
training. Everyone needs to be challenged in positive ways in order to grow and 
learn. Unfortunately, individual growth plans rarely make it past the first meet- 
ing, and too often a well-designed growth plan ends up being ignored or forgot- 
ten. To combat this, short but frequent check-ins with team members, instead of 
quarterly or annual reviews, will keep the individual’s attention on their plan, 
while using their goals as a lens to focus activities. Reminding a team member of 
one of their OKRs (objectives and key results) has the same effect as removing 
distractions from their plate: it refocuses them on what’s really important. Quar- 
terly and annual reviews are too spread out and will not have the impact required 
in fast-moving product teams. 


Successful leaders don’t assume that hiring smart people is enough, just as they 
understand that using smart tools or processes is not enough. Without the right 
guidance and direction, neither great people nor perfect processes will produce 
good results. Ongoing, regular, and consistent training has the additional benefit 
of teaching teams the value of process—eating your own dog food, if you will (or 
as we prefer to say, drinking your own champagne). 


In the sections that follow we will dive deeper into the various challenges facing 
different types of organizations. Startup teams are, and should be, very different 
from enterprise teams. However, the approach toward making these teams suc- 
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cessful can be common to all. Focusing on a common problem that’s well articu- 
lated and then building a structure that reinforces that focus is the common 
thread in all team development. Keeping a clear connection between the bigger 
team goals and individual OKRs is a daily or weekly responsibility for product 
leaders that is well worth the time and effort. 


MANAGING UPWARD AND OUTWARD 


Being a product leader means being the middle of the sandwich, squashed 
between senior stakeholders (executives, investors, board members, etc.) and 
your product team (designers, developers, marketers, etc.). As if that’s not 
enough, they also have to deal with inputs from other departments, customers, 
partners, and occasionally, the media. Developing a holistic view of the product 
environment and understanding that the product doesn’t live in isolation will 
bring clarity. The work of leading product creation is not about technology—it’s 
about the ecosystem and, in the words of Vanessa Ferranto, Head of Product at 
Zipcar, “about understanding that the product isn’t just software or hardware, it 
is the entire experience and the community.” Leadership at any level is a commu- 
nity position. For product leaders this is even more the case given their pivotal 
role. 


Managing the expectations of senior stakeholders isn’t simple, but it is possible. 
“In the first part of my career, I was really focused on putting myself in my cus- 
tomer’s shoes. Now, I’m trying to be just as conscious about stakeholders too,” 
reflects GrubHub Senior Product Manager Rose Grabowski on her increasing 
empathy for stakeholders. “Not just thinking about what drives them, but really, 
deeply thinking if I were them, what would I want? In this case, I’m thinking 
about the sales team, the engineers, the marketing people, all the internal stake- 
holders. I’m trying to really empathize about their concerns, and ensure I take 
those concerns into account at a deep level. I try to put myself in their shoes.” 


Once again, the product leader finds themselves dealing with people, their indi- 
vidual needs, and their unique personalities. Mapping the ecosystem of stake- 
holders using one of the persona exercises will give the leader the chance to 
visualize the people in their product ecosystem and assign qualities to them. 
Knowing who is a potential roadblock and who is a decision maker allows the 
leader to develop strategies to deal with those individuals. Going a step further 
and developing an experience map of the organization and its environment deep- 
ens the product leader’s insights. This might sound like a lot of extra work, but it 


WHY IS PRODUCT LEADERSHIP SO RELEVANT? | 29 


offers useful benefits. Being able to identify obstacles and orchestrate solutions 
around those potential blockers can mean the difference between shipping and 
not shipping. Persona maps, who/do exercises, empathy maps, and experience 
maps (see Figure 2-3) need not be complex. A few hours constructing or sketch- 
ing these realities will give the product leader the ammunition to deal with what 
might otherwise be a frustrating ambiguity. 
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Figure 2-3. Experience map (source: Fresh Tilled Soil). 


Again, it is apparent how the tools we use for product creation are equally useful 
in the context of the product leader role. Employing the exercises available for 
successful product design and development to manage the team will give the 
product leader a significant advantage. 


ALIGNING AND FOCUSING THE ORGANIZATION 


We've discussed the topic of aligning the organization toward a common vision 
several times in the context of hiring, team building, and managing other 
groups. It’s such an important topic that it’s worth a little more attention, how- 
ever. The reason it is so important is that a common vision is the hub to which 
all activities and decisions are connected. It is the lens through which the organi- 
zation finds its focal point, aligns the entire team’s energy and attention, and 
reminds them what isn’t important. Much like a set of values, a vision clarifies 
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what’s going to be part of the organization’s future and what will be ignored. 
“The challenge is clearly communicating that vision to everybody on the team 
such that they understand how they are contributing to it,” says Jeff Veen of True 
Ventures. Humans do well in situations where there is a clear description of the 
future they are headed toward. This natural behavior translates to business and 
product visions. Aligning the team’s daily activities with that vision allows your 
team to connect the dots and see the path ahead more clearly. “If you can connect 
those dots for people, they’re gonna be so happy,” continues Veen. “There’s all 
kinds of other factors, but if they know the work they’re doing today is going to 
contribute to a vision they believe in, in a measurable way, man, that’s golden.” 


A vision isn’t a poster on the office wall or a weekly newsletter to the team. It’s a 
concept of what the future will look like with the energy to back it up and some- 
thing that should be regularly communicated to the team. Regular all-hands 
meetings and onboarding training are examples of how this can be communica- 
ted. A single viewing of the corporate video is not enough. The company vision 
should be mentioned or presented weekly if possible, and included in all team 
meetings and in all-hands meetings. 


Mike Brown, Product Manager at PatientsLikeMe, underscores how critical a 
shared vision is: “In any product that you’re building it’s important to align all 
the different people in the system. It’s not just about creating an ideal experience 
from the UX side or about having the right structure of data from the research 
side or engineering side, and it’s not just about making money on the business 
development side. You really have to bring all of these things together. It’s often 
a diverse group of people who have different opinions about how things should 
work or what we should do to solve a certain problem. As a product person, if you 
don’t have a passion for the things you’re doing, it’s going to be really hard to 
rally a diverse group of very bright people around an idea to actually not only 
define what it is that you are going to be solving, but also how it will be exe- 
cuted.” 


The importance of vision cannot be overstated. In the next chapter we'll explore 
vision setting in detail. 


Being a Great Product 


=H 
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Management is about doing things right; 
leadership is about doing the right things. 


—PETER DRUCKER 


Setting Product Principles 


In order to set your team up for success as it scales, it’s important to consider 
what the core product and design principles for your organization are—and artic- 
ulate them clearly so everyone in the team understands them and can apply them 
in their work. 


Says Paul Adams, VP of Product at Intercom, “We have three principles that are 
the foundation on which everything else that we do is built. The first principle is 
that we think big but start small. This means thinking about a big vision and 
then ruthlessly cutting the scope so we can ship. Because our next principle is 
ship to learn, which means shipping as fast as possible so we can learn as fast as 
possible. The third principle is to design from first principles—to start with a 
blank sheet of paper instead of copying a competitor or assuming the best solu- 
tion exists in the world already.” 


These principles set the groundwork for all future product work, and give the 
team a common set of guardrails that can guide all the minute decisions that 
make up each iteration of the product. 


Setting a Product Vision 


Jeff Bezos, CEO and founder of Amazon, said, “Be stubborn on vision, flexible on 
details.” The vision should continue over a very long period of time, potentially 
years. The best product visions are timeless and disconnected from the technol- 
ogy they are built on. In a startup, the vision is usually championed by a founder 
or an early-stage CEO. Their responsibility is to remind the organization’s people 
—throughout all the product decisions and product roadmap discussions—of 
that vision. “When I joined the company in 1992, we used to talk about our mis- 
sion as putting a PC in every home, and by the end of the decade we had done 
that, at least in the developed world,” says Microsoft CEO Satya Nadella. “It 
always bothered me that we confused an enduring mission with a temporal 
goal.” Disconnecting from time and trends is essential to creating a long-term 
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vision—because, ultimately, achieving the objectives determined by a clear view 
of the future makes for a better product. 


The company vision is unlikely to change much. Pivoting a company or product 
doesn’t necessarily mean changing the vision. If described correctly, a vision will 
be timeless and not connected to technology or trends. Disney’s vision to “Make 
People Happy” doesn’t need to explain how that gets done. A vision should be 
able to stand the test of time while also being translated into near-term goals, 
objectives and key results (OKRs), or roadmaps. The OKRs and roadmaps can 
change; in fact, they should change as new information is received from the mar- 
ket and from customers. This adaptation of the near-term goals shouldn’t have 
any effect on a well-constructed and timeless vision. 


“One thing I’ve seen for myself and for others in the past, is having a tough time 
showing the roadmap knowing it’s going to change,” says Rose Grabowski, previ- 
ously Director of Product Management at Invaluable and now Senior Product 
Manager at GrubHub. “It’s always going to change ‘tomorrow.’ Even when you 
get to tomorrow, it’s going to change the next day too. Maybe not literally tomor- 
row, but you know you're always learning and thinking about course correction.” 
Grabowski describes a familiar environment for all product people: working in 
an ambiguous world of shifting deadlines and fresh problems to solve: “It’s 
tough to say, ‘We’re going to show something and we’re going to couch it with all 
sorts of notes on this being a living document. Things always change. These 
aren’t committed dates.’ That kind of thing.” Grabowski has homed in on the 
counterintuitive nature of the product leader’s job—having a clear long-term 
vision while simultaneously living in a shifting short-term world of tasks and 
deliverables. 


An additional challenge is that once a team sees the vision and the roadmap, they 
get attached to the outcomes. “[People] hope that nothing will change, or at least 
the thing that they don’t want to change, doesn’t change,” says Grabowski. Align- 
ing a vision and managing the daily activities to get there means regularly shar- 
ing that vision while at the same time reminding your team that the details of 
how you get there will change. That change is guaranteed, so it’s important to 
have the conversation and just accept that nothing is perfect. Overcommunicate 
if necessary, because, as Grabowski reminds us, “undercommunicating the road- 
map is a big mistake that can easily be made.” 
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The product leader assumes the same responsibility and champions the vision at 
each step of the product creation process. The product leader always needs to be 
asking, how does the big problem we’re solving relate to the ultimate vision? Will 
the product live up to the vision? How is the vision being communicated? How 
often will this vision be communicated or presented? Who is responsible for the 
vision communications? 


Regardless of what the vision is, it is essential to have an advocate constantly 
reminding people about it; in some of the companies we interviewed, company 
vision is woven into weekly meetings and into almost all all-hands meetings. 
This advocate can and should be the executive team and the product team, but in 
some cases can also include an external advocacy group. Titleist, the manufac- 
turer of premium golfing products, has a group of customers that are part of the 
company’s inner circle. They are included in conversations about new products 
and innovative ideas. During a recent web and mobile project, these customers 
got to see early-stage designs so they could provide constructive feedback and 
direction. The customers are explicitly asked if these new digital products will be 
consistent with Titleist’s stated vision “to serve the needs of the serious and rec- 
reational golfer with value added products and services that have a competitive 
advantage worldwide.” 


Ultimately, where the vision comes from is less important than ensuring that it 
is the correct one. As product management guru Rich Mironov says, “It’s not 
important to me who has the good idea, but it is my job to make sure it’s the best 
one, that it’s still validated, and that we have people who are going to pay for it. 
The process has to continually validate the vision. If we do that, I don’t care 
whose vision it is.” 


Moving from Vision to Strategy 


The most common question from tactical leaders about the organizational vision 
is, how does it translate into a product roadmap? How do you take the vision and 
ensure that the steps along the road reach that horizon that holds so much 
promise for the organization? These are important questions, because one of the 
challenges product teams face is that roadmap-related decisions are often made 
that are disconnected from the strategic goals of the organization. In any size 
organization, it’s important for product managers to work with and educate 
stakeholders about the company’s priorities and goals. Getting buy-in from the 
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stakeholders for the four or five or six things that are going to be accomplished 
during the year is the first step. Once that is achieved, the product manager must 
work with the stakeholders to define the initiatives that will fit those strategic 
goals. This early collaboration will be far more productive than having a product 
manager operating in a vacuum and unilaterally creating a product roadmap of 
where they’re going to be, and it becoming set in stone. 


The vision gives rise to specific product goals. These product goals could be 
things that must be accomplished over the next year—for example, growing reve- 
nue, reducing churn, and improving customer satisfaction—or they might be 
more strategic product goals. Whatever they are, the goals, like the vision, should 
be championed by product leadership; whether the founder of the company, the 
VP of Product, or the Director of Product, it’s important that the product leader 
constantly revisits those individual goals in order to support the overall vision. 


“Were very goal focused,” says Paul Adams, VP of Product at Intercom. “Pretty 
much everything we do is oriented at a goal. We have company goals. Specific 
teams have their team goals. And we do this at pretty much every level of granu- 
larity, so we'll have quarterly goals that we'll break down into weekly goals that 
will break down into daily goals—and they all cascade. You could take an engi- 
neer’s daily goals and map that to a weekly goal they have, map that to a six-week 
goal our team has, which would map to a quarterly goal that the product and 
engineering team has, which would map to a company goal, etc.” 


Out of the goals will come the specific features for development. Like a ripple 
effect with the vision at the center, the objectives or goals are generated and they 
in turn generate the features that support those goals. Never start with features. 
Even if your business or product is based on a “feature concept,” ask yourself 
what the bigger problem is and why it needs solving. Any feature shouldn’t be 
considered, prioritized, or delivered in a vacuum. Without a vision to guide the 
product creation, a project can quickly become a collection of cool solutions lack- 
ing a core problem to guide them. Features need to be directly tied to the product 
or organization’s strategic goals. 


“The product vision is really what our products are going to deliver and for 
whom, but it’s a bigger view,” says Tim Buntel, VP of Products at XebiaLabs. 
Buntel, who has served product roles at Atlassian, Microsoft, Adobe, Codiscope, 
and now the DevOps company XebiaLabs, sees a smooth transition between 
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vision and strategy. “Product strategy is about how you attain that vision. It could 
be your value proposition, it could include key feature areas, and [it] could also 
include business goals. That strategy might extend a year or so out into the dis- 
tance.” Buntel knows that key feature areas tend to change once you get past that 
one-year horizon. He believes that a vision is long term, but the strategy is proba- 
bly no more than a year or so. “The roadmap is even shorter, maybe six months 
out. It tells how the key features will come in actual releases.” 


Buntel has observed that product leaders are always seeking order in an inher- 
ently chaotic environment. This influences their thinking and forces them to 
become attached to structures and tools. “The world that we’re in right now is 
very fast-moving. I think a challenge as a product manager is to allow yourself to 
be flexible with your vision and understand that these things can evolve really 
quickly. You need to be able to go along with some of those natural evolutions.” 
The qualities that allow for adaptation are just as important to product managers 
as any of the other skills identified here. Product management might not be the 
right career path for a person that is averse to change. 


Finding ways to adapt will also serve the broader team as they encounter inevita- 
ble outside pressures. Market disruptions and environmental changes can all but 
destroy a company. Product leaders need to assume change will happen, and 
sometimes that change will be out of their control. We’ve witnessed new compa- 
nies like Airbnb, Uber, Tesla, and Slack shake up established industries and pro- 
vide a new landscape for operators. Product leaders that are affected by this 
forced adaptation need to jump into action. Having a vision that can accommo- 
date unexpected externalities means being able to adapt faster to change. Because 
the product strategy hangs off the product vision, it’s important to have a flexible, 
timeless vision. 


Moving from Strategy to Roadmap 


When you're looking at the finished work of a well-executed product, it seems 
perfect. All you can see is the beautiful presentation and anticipate the potentially 
enjoyable experience ahead of you. Of course what you don’t see is all the hard 
work that went into the creation of this sensory masterpiece. You don’t see the 
people and processes that go into making that amazing thing. The same is true 
of almost all beautiful products. Behind every great product is a great team doing 
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work in a way that guarantees results. They are following a roadmap from the 
starting point to the end product. 


Here is just a sampling of the people and elements involved in any great product: 
product leader and/or manager, product team (designers, engineers, QA, etc.), 
components, roadmap, tools, UIKit, marketing team, and a marketing website, 
and of course, customers. Remove any one of these elements, and the outcome 
will be different. As with baking a cake, changing any of the ingredients (team 
members) could result in a completely different cake. Sometimes this will be 
good, but many times it will be an outcome you didn’t plan for and your custom- 
ers won't want. If you’re selling chocolate cakes and suddenly they start coming 
out strawberry flavored, you’ll have some unhappy customers. 


It’s also true that if you stick to the recipe and process too closely, you’ll never 
experience any opportunities for improvements or moments of delight. This is 
why the best chefs run a rigorous and disciplined kitchen but also make space for 
experimentation and improvement. The trick is in getting the guiding framework 
right and allowing for flexibility inside that framework. In product creation cir- 
cles, this is what’s often referred to as the roadmap. It’s not a replacement for a 
rigorous process or a smart team. It focuses the people and process on the best 
outcome for the customer. So how does a roadmap help you deliver on the prod- 
uct work? 


Focus 
First it puts a lens over the work and focuses in on the core value. Humans 
not only want focus, they require it to do their best work. The roadmap also 
helps us understand what we won’t be giving our attention to. If we stick to 
our cake baking metaphor, we would say, “We’re making the best cake. Not 
cookies, not brownies, just cake.” 


Alignment 
The roadmap also helps create alignment. It gets the entire team working 
toward the same goals. Once the roadmap has been discussed, the team 





1 Several parts of this section on roadmapping gained color and clarity after our conversations with the 
authors of another O'Reilly book called Product Roadmapping: How to Prioritize Your Opportunities, 
Align Your Teams, and Deliver the Most Value to Your Customers and Stakeholders (hitp.://oreil.ly/ 
200Aka2), C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors. We're very grateful for 
their insights and for giving us permission to share their wisdom and knowledge here. 


38 


PRODUCT LEADERSHIP 


will have clarity on what their roles are and what their efforts will create. In 
our kitchen, we’d hear, “Were all on board with the cake flavor, styling, 
and time it’ll take to get it from start to finish.” 


Priority 


Knowing what to do is half the story; knowing when to do it is the other 
half. Prioritization is a core part of having a roadmap that works. Another 
way to look at it is to substitute the statement, “We won’t have time for 
that” with the clarification, “That isn’t a priority for us to be successful.” 


Visibility 


Seeing the way the team works and what they will be doing makes every- 
thing easier. Roadmaps help us visualize potential pitfalls and opportuni- 
ties by organizing the work in terms of priority and importance. If it’s 3 
p.m. and our cake needs to be on the shelves by 10 a.m. the next morning, 
then working backward, what do we need to be doing between now and 
then? 


Coordination 


Overlapping efforts or misaligned work that cancels out our progress 
causes stress and waste. Getting our team working in a rhythm is a big part 
of creating and maintaining momentum. Everybody should know their 
contribution and how it dovetails with the others on the team. The old say- 
ing “too many cooks in the kitchen” is too perfect not to add here. 


Vision 


The best companies and products have a clear vision of where they are 
going. A great vision should paint a picture of a brighter future for your 
customers. It’s not about you. It’s about them. As mentioned earlier, the 
most famous, and possibly one of the best, customer-centric visions was 
Disney’s original “Make People Happy.” It’s simple and easy to use as a 
lens for what needs to be done each day. You’ve just delivered a tasty and 
beautiful cake to your hungry customer. What is next for your relationship 
with them? A roadmap should paint a picture of what comes next to ach- 
ieve a long-lasting relationship with your customers. 


Now you know what’s in your roadmap. But before we go any further and discuss 


how to create a roadmap, it’s important to clarify what a roadmap is not: 
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e Itis not a release plan—leave out specific dates and timelines. 


e Itis nota list of features and/or components, nor should it include job sto- 
ries, user stories, or “jobs to be done”; these are too granular for a road- 
map. 


e Itis not a commitment. It is a living guide that reacts to new information. 


e It is not one monolithic document. Given that we argue for small, autono- 
mous, cross-functional teams focused on specific areas of the product, 
there should be a roadmap per team. 


e A successful roadmap is not a Gantt chart. Dependencies and waterfall 
connections won’t work for this level of planning. 


ProdPad’s Janna Bastow underscores these points: “The place where I see road- 
maps falling down is when people start putting concrete dates on them. There’s a 
big misconception about what a roadmap is and what it isn’t. I see it as an arti- 
fact that communicates the direction you’re going to meet the product vision. It 
is a completely separate document—or it should be a completely separate docu- 
ment—from the release plan, which outlines what’s being launched and when 
and who’s working on what. They’re both valid documents, but when people try 
to combine them, you essentially end up with a Gantt chart with dates stretching 
out—not just from the first one or two quarters that you can plan for, but beyond 
that. I always point out to people that you don’t know how big your company’s 
going to be by December, let alone how fast you’re going to be able to deliver.” 


Matt Walton, Chief Product Officer at FutureLearn, adds: “Each of our teams is 
responsible for their own roadmap. It’s down to them how they achieve the mis- 
sion they’ve been set and move the metric that we have made them accountable 
for. The key thing to remember with a roadmap is that the document itself is 
uninteresting—it’s the process of understanding and negotiating that the team 
goes through, to own the problems and commit to solving them, that is its real 
purpose. Where as once our roadmap was a single beautiful published document 
made in Keynote, they are now organic, living, and collaborative Trello boards 
owned by each team and so much more useful because of it.” 


The best roadmap, therefore, is a strategic communication artifact that is focused 
on the big picture and conveys the path you'll take to fulfill your product vision. 
“More often than not, the lack of a roadmap encourages you to do too many 
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things not as well,” says Anthony Accardi, CTO of Rue La La. Who will use the 
roadmap once it’s complete? Well, everybody: product, design, development, 
sales and marketing, executives, customers, partners, and customer support. 


FOCUSING THEMES ON CUSTOMER PROBLEMS 


Because it’s a strategic document, what you want to convey in your roadmap is 
not a series of features or solutions but themes around the customer problems 
you intend to focus on and work on. 


Shifting a roadmap to themes can be incredibly powerful. As User Interface 
Engineering’s Jared Spool says, “Themes are a promise to solve problems, not 
build features,” which in one stroke makes learning about the customer the most 
important thing the product team can do. If you only prioritize customer prob- 
lems, then you need to understand those problems first. 


This also simplifies your roadmap, as one customer problem can encapsulate 
multiple features, as well as the prioritization process, because only those fea- 
tures or ideas that focus on solving that customer problem make the cut. 


“Product managers usually have hundreds of features on their roadmap that they 
try their best to prioritize,” says product consultant Bruce McCarthy, “but they 
haven’t usually gone and dug underneath the request to understand the real 
underlying need, to understand the problem that the customer wants solved.” 
Each of those features adds up to a lot of little fixes and effort, but with a little 
digging the true underlying issue comes out—a theme that lets you tackle a 
larger customer problem more comprehensively than merely a series of small 
fixes. 


PRIORITIZING GOALS AND STRATEGIC ACTIVITIES 


“Too often we think we have a good idea, but we’re starting on the supply side,” 
says Ryan Singer, Product Manager at Basecamp. “We’re looking for excuses to 
build the thing that we want to build, and the real trick to going deeper with 
product is to learn to move backward and get into the demand side and ask: Why 
is this the right time? Why is this important? What matters right now?” 


We'll talk in detail about prioritization in other sections of this book, but as it’s 
essential to the roadmap creation process, we need to address it here too. Let’s 


BEING A GREAT PRODUCT LEADER | 41 


start with how not to prioritize your strategic goals and activities. Knowing what 
filters not to use is as important as knowing what filters you should use. 


Your CEO’s gut reaction to a feature is not a good place to start. It’s not that your 
CEO isn’t smart or doesn’t have great insights; but all subjective opinions are fre- 
quently influenced by personal bias. Similarly, requests from sales teams or sup- 
port teams reacting to one or two customer requests need to be checked for 
consistency and relevancy to the broader customer base. Prioritizing a feature 
because one customer says they need it will set a precedent for this kind of inter- 
ruption to the workflow. We also recommend not relying too heavily on analyst 
opinions either. These industry pundits are basing their suggestions on historical 
and aggregate sector data, so beware of using them to forecast the future of your 
narrow market. Of course, all of these sources are valid, just not in isolation and 
never at face value. 


So if these sources of information should be either distrusted or double-checked, 
what sources should you trust? Prioritization is best done through the lens of the 
core product management principles: 


e Valuable 
e Usable 


e Feasible 


Valuable and usable are the core customer-focused parts of the prioritization pro- 
cess. Is this new idea, product, or feature valuable to the customer? Is it valuable 
enough to be valuable to the business? Is it delightful for the customer to use? 
This of course has to be contrasted with the technical (and business) feasibility of 
the idea. Can it be built in a cost-effective manner? What is the cost to service and 
support it? Only by looking at the full picture like this can you prioritize one idea 
against another. 


MANAGING THE UNKNOWN 


Often when prioritizing new ideas, features, or products, you simply don’t have 
all this information to hand. So inevitably most teams start guessing what the 
impact might be, what the dev effort might be, and so on—leading to personal 
biases and assumptions that tend to overestimate impact while underestimating 
effort. 
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The key to solving this is to embrace ambiguity and focus just as much on learn- 
ing about your customers as on features. Most product leaders we spoke to talk 
about this in the form of hypotheses, and spend a lot of time and effort on 
quickly validating these hypotheses through testing. Using the language around 
hypotheses removes the ego from the results. 


“I like my teams to think in terms of bets. By proposing ideas in the form of ‘I 
bet that by doing X we'll see Y, sharing your thoughts becomes less risky than 
stating a more formal hypothesis. If your bet is wrong, you might feel bad, but it 
was a bet—nothing more. Using bets lightens the mood of creating and sharing 
ideas. Plus, bets work into people’s vocabulary much easier than hypotheses—it’s 
a great step toward actually building a culture that encourages experimentation,” 
says product management consultant Kate Leto. 


Small bets 


If you’re optimizing an existing, mature product, the best way to get data to back 
up your assumptions is simply to start testing your bets using a/b or multivariate 
testing. This data-based approach short-circuits any arguments or biases by 
showing what actual users or customers do when confronted with new affordan- 
ces. With the testing frameworks and tools available today, there’s no excuse not 
to be doing this either. Beyond installing a testing library, your engineering team 
doesn’t even need to be involved! 


Bear in mind, though, that focusing solely on optimization can blind you and 
your team to the bigger opportunities that might be out there. In striving to con- 
stantly optimize the details on a current product, you will inevitably achieve a 
local maximum, but you might be missing the global maximum potential if you 
don’t take bigger bets. 


Large bets 


When it comes to making larger bets on new product lines or completely new 
features, multivariate testing just doesn’t work. This is where most product lead- 
ers fall back to the MVP (minimum viable product) approach. This concept came 
out of Eric Ries’s 2011 book The Lean Startup (Crown), but the term has become 
so overused it’s lost its original meaning. 


“MVP is often mistakenly applied to the first release of a rudimentary product, 
and as a result, the ‘MVP’ ends up much more complex than the quick test it was 
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supposed to be and far too shoddy for a released product,” argues Rik Higham, 
Senior Product Manager at Skyscanner. 


Instead we should focus on learning and put the emphasis on testing our riskiest 
assumptions. “A RAT, or riskiest assumption test,? is explicit,” Higham contin- 
ues. “There is no need to build more than what’s required to test your largest 
unknown. No expectation of perfect code or design. No danger it will prema- 
turely become a product.” 


MAPPING AMBIGUITY TO TIME 


While the product leaders we interviewed uniformly eschew timelines on road- 
maps, it is of course a document showing what you intend to focus on over time, 
so some dates are important to convey meaning. The best roadmaps simply divide 
time, and your themes, into what the team is working on currently, what is 
queued up to come next, and big-picture ideas for the future, with varying 
degrees of definition and flexibility (see Figure 3-1 for an example). 
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Figure 3-1. Roadmap concept courtesy of Janna Bastow, CEO and cofounder of Prod Pad 


Putting your roadmap together is ultimately an exercise in planning your activi- 
ties into ever-increasing time periods. As DJ Patil, recently US Chief Data Scien- 
tist, has said, “Dream in years; plan in months; evaluate in weeks; ship daily.” 
Start thinking broadly and then narrow down your efforts to the shortest time 
frames. Implicit in this idea is that the roadmap is dynamic and requires contin- 
ual updating. Like all tools and artifacts at the product leader’s disposal, these 





2 Rik Higham, “The MVP is dead. Long live the RAT.” 
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roadmaps are only as good as the information that goes into them and the atten- 
tion they receive. Failing to communicate this roadmap clearly and frequently 
will make it less effective. 


Product Is a Team Sport 


As we’ve noted, many define product leaders as the CEO of their product, but 
this fundamentally misunderstands the role and, worse, sets up for failure any 
product leader buying into it. 


A better analogy would be the product leader as the captain of a sports team, a 
conductor of an orchestra, or a university professor guiding their class. Like the 
professor, conductor, or team captain, the product leader is an individual who 
succeeds only by bringing the whole team along with them, working toward a 
common goal. 


As we’ve outlined, in almost every organization product managers have no direct 
authority over engineers, designers, marketers, or any other members of the 
product team. This oversight of organizational theory may seem like a bad thing, 
but it forces product leaders to exercise true leadership, and not to manage by 
authority and dictate alone. 


The product leader’s job is not to constantly manage or direct, but to lead their 
team by clearly articulating the common goal. They should provide the context 
the team is working in, from the problems and frustrations the customers have 
to the competitive environment the company operates within. If nothing else, 
this is what you will get out of this book. 


True leadership recognizes that the whole is greater than the sum of the parts. 
Being dictatorial and enforcing your own product ideas is never going to be as 
productive or successful as bringing the whole team, from design and engineer- 
ing to sales and marketing, together. The product leader’s job is to curate the 
right team, provide an environment for success, bring the user problems to 
them, and then facilitate conversations and help connect the dots so the whole 
team can design the solutions together. 


When you're designing solutions it’s so valuable to involve the whole team, with 
their diverse mindsets and experience, that it would be foolish not to. Every job in 
a tech company is an inherently creative role, whether it’s obvious (designers) or 
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not (engineers). Some of the best product solutions we have worked on have 
come from engineers who have such a good understanding of the problem space 
(thanks to a great product leader), and an inherent grasp of the opportunity affor- 
ded by the technology stack, that finding quick, elegant solutions to customer 
needs is second nature to them. 


The bottom line is that everyone in the company owns the product, and its suc- 
cess or failure lies in the hands of each person who touches it. It bears repeating 
that a product leader’s job is to create the best team possible, to lead them to 
tackle the product challenges together, get the best out of everyone when build- 
ing the product, and provide a gentle hand to keep it heading in the right direc- 
tion. 


DESIGNING A PRODUCT TEAM 


“Product is people. Every single person in your organization influences the cus- 
tomer experience in some way, so the experience your customers have is a direct 
outcome of the people you hire and the decisions they make,” says Nilan Peiris at 
TransferWise. “There’s a myth in the corporate world that people do what you tell 
them to do, but in reality they only do what they want to do, so you have to build 
a culture that influences those decisions in the right direction.” 


In traditional product management, decisions get made in line with the account- 
ability structure, from shareholders through the CEO down to the product teams. 
Because the accountability and the decision making sit at the top tier of this org 
chart, the feedback loop to the actual customer is far too long. This creates top- 
down plans, little or no accountability at the team level, and ultimately, unhappy 
customers. 


A new organizational model is emerging, from extremes like Holacracy to the 
scaled, Agile approach of Spotify, that realigns the accountability structure 
around small, independent, cross-functional teams. This offers them full 
autonomy to discover what their customers need and execute the delivery of that 
product in whatever way they see fit. 
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TransferWise has built fully autonomous product teams with clear KPIs (key per- 
formance indicators}? but otherwise total freedom to set their roadmap, decide 
their organization, and build the team and resources they need to execute their 
plan. Any team can change any part of the product. So, for example, marketing 
doesn’t have to wait for product to build what they need; they have full access to 
build pages, change user flows, or do anything else necessary in pursuit of their 
goals. 


At Pluralsight, teams have complete autonomy and are cross-functional and col- 
located. They do not stand up a team unless this team composition is possible to 
achieve. Each team discovers, builds, and delivers on their own to a production 
environment. These teams control their experience and the experience of their 
customers in its entirety (see Figure 3-2). 
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Figure 3-2. David Platt (left) leading a customer preference test for the Pluralsight learner experi- 
ence. 


Spotify developed one of the better-known models around this autonomous 
approach. They start with squads, independent teams that sit together and have 
all the skills and tools needed to design, develop, test, and release their part of the 





3 A quantifiable measure used to evaluate the success of an organization, employee, etc., in meeting objec- 
tives for performance. 
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product to production. Each squad self-organizes and decides its own way of 
working. Some use Scrum sprints, some use Kanban, and others use a mix of 
these approaches. Squads are grouped into tribes that work on related areas of the 
product, and are never allowed to exceed the Dunbar number.‘ In order to coordi- 
nate functional best practices (for example, design) across these teams, they 
introduced chapters and guilds to share knowledge and experience across squads 
and tribes. 


However it’s described, this idea of small, autonomous, cross-functional teams 
that can get close to the customer is an increasingly important factor in great 
product leadership. It is not perfect: too much autonomy risks losing economies 
of scales and introduces both dependencies and alignment challenges between 
teams. However, almost everyone we spoke with aspired to this ideal. That trade- 
off decision is key, as it emphasizes the customer’s central role in the develop- 
ment of great products, and makes the coordination challenge internal instead of 
external. Autonomy motivates teams better than the old carrot-and-stick model, 
and as a team structure, it scales better and moves faster than any top-down 
model. In today’s fast-moving world, your team has more information, experi- 
ence, and knowledge about the customer problem and the specific product area 
they’re working on than you ever will, so why try to drive their priorities when 
they have more information? 


“Traditional management is great if you want compliance, but if you want 
engagement, which is what we want in the workforce today as people are doing 
more complicated and sophisticated work, autonomy and self-direction just 
works better,” shares Dan Pink, author of Drive: The Surprising Truth About What 
Motivates Us (Riverhead). 


If you are not evolving your organizational design, it might be an indicator that 
your product strategy is getting stale. In our experience, most rigid organiza- 
tional structures are built to create processes for predictability, not successful 





4 This number was first proposed in the 1990s by British anthropologist Robin Dunbar, who found a corre- 
lation between primate brain size and average social group size. By using the average human brain size 
and extrapolating from the results of primates, he proposed that humans can comfortably maintain only 
150 stable relationships. 

5 Overly autonomous teams risk losing the benefits of interdependent organizations. A lack of information 


cross-pollination and efficiency from centralized processes is possible, albeit unlikely, in a well-managed 
company. 


48 | PRODUCT LEADERSHIP 


outcomes. The problem with this is that not only does it support a command- 
and-control philosophy, but it also must exist in a static state in order to provide 
data. We prefer a process that has the ability to evolve, however marginally, every 
quarter or year and to set the expectation that we should restructure as needed. 
The same goes for the discovery and delivery teams. The organizational model 
we just shared will continue to evolve to better support our teams over time, 
knowing that this is not how we may operate a year from now. The scaffolding of 
supporting teams should remain, but we may reconfigure it depending on what 
we are working on, making leadership changes and team moves as required. The 
decision to do so comes from our teams, who have their finger on the pulse of 
our customers and understand what needs to be done to execute on a solution. In 
an ideal situation, the product team isn’t making decisions based on a burndown 
chart or efficiency flow metrics; rather, the team is making decisions based on 
customer outcomes. 


Diversity 


Diversity in a team should be the imperative. From the beginning of an organiza- 
tion’s journey, diversity will serve the overall best interests of the entire team and 
the product itself. The tech world suffers from a lack of diversity, and this is often 
reflected in our products and the challenges they face in the market—from every 
major social network’s inability to manage online harassment to an overabun- 
dance of startups aiming to solve white, upper- or middle-class problems. 


A good product team needs a mix of design, tech, and business; a mix of genders, 
creeds, and backgrounds; a mix of industry experience and product management 
experience; and a mix of skills, from the visionary to the detail-oriented, from the 
data-hungry to the user-research fanatics. This level of diversity not only is the 
best chance you have of representing your audience, but also ensures the best 
experience is brought to any product challenge the team will face, and is the best 
defense against any one individual’s confirmation bias. 


James Keller, who leads strategy at Uncorked Studios in Portland, has a great 
name for diversity in product creation: “Building great things requires diversity 
of age, skills, and experience. We call that ‘people soup.’ Organizations need 
structure and hierarchy to get validated ideas built into products, but the initial 
ideation and concept development needs less structure and more chaos. Product 
creation needs the chaos of people soup. Once the early phases are done, more 
structure is needed.” 
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There is a wealth of research that underlies the value of diverse teams and shows 
that being around people who are different from us makes us more creative, 
more diligent, and harder-working,° and has also been proven to make compa- 
nies more innovative and successful.” 


Mina Radhakrishnan shares how she approached diversity in building the prod- 
uct team at Uber: “For me, it was really important to make sure that we had 
diversity in our group, because I think it’s really important to have women, peo- 
ple of color, and minorities in leadership roles to encourage diverse thinking. 
One of the ways we did this was to really look for people who didn’t necessarily 
have exactly the same background as us, rather than rely on the kind of pattern 
matching that I think is so prevalent when it comes to recruiting. 


“The second product manager at Uber, for example, was an ex-McKinsey consul- 
tant, and is probably one of the best PMs I have ever had the privilege of working 
with. She had a completely nontraditional background. She did go to Stanford, 
but in terms of the work that she had done and the way that she thought about 
things, she just presented herself very differently. In just looking at her résumé 
you would not have thought she was a product person, but she was a complete 
natural. 


“What we did was create exercises for people to do as part of applying to the prod- 
uct management area. In the process of looking at those exercises, we found peo- 
ple who really showed the right user-centric product thinking we were looking 


” 


for. 


CROSS-FUNCTIONALITY 


When we say cross-functionality we don’t just mean product, design, and engi- 
neering (although that’s a good start). The best teams go further, and contain 
everything needed to execute their area of the product, from legal to marketing. 


For example, at TransferWise, the currencies team contains lawyers and bankers 
in addition to the product manager, designer, and developers, so that they can 
manage the local bank accounts and regulatory requirements required to launch 


6 Katherine W. Phillips, “How Diversity Makes Us Smarter”, Scientific American, October 1, 2014. 


7 Sylvia Ann Hewitt, Melinda Marshall, and Laura Sherbin, “How Diversity Can Drive Innovation”, Harvard 
Business Review, December 2013. 
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new currency exchange paths. Imagine how much more efficient this is than hav- 
ing to coordinate with a separate legal or banking department within the com- 
pany to get this more basic part of their work done. 


Each internal interface between teams or departments creates unnecessary addi- 
tional friction and requires processes for queueing and prioritization. True cross- 
functional teams can skip all of that and execute much faster because of it. 


Eternal optimism 


The teams we are describing are eternally optimistic, are full of energy, and have 
an unquenchable appetite to understand. They deconstruct problems, build the 
best idea for the customer, and have an unbridled passion that needs to be reined 
in at times. They start with a learner’s mindset. This might sound a little like uni- 
corns and rainbows, but the reality is that great teams deliver from a positive atti- 
tude. 


The best part of having diverse, cross-functional, and optimistic product teams is 
that much of the personal bias is reduced because the user breaks the tie. It’s 
unlikely that all bias will be removed, but gone are individual contributors fight- 
ing over who has the better idea. It’s purity at its core. These teams can be implic- 
itly trusted with any vision, strategy, or idea because they know how sacred it is to 
respect and deliver something truly meaningful to the user. Their individual 
roles cross over and intersect naturally. It is not uncommon to see a user experi- 
ence designer sitting next to a developer learning how to pair and code, or a 
developer interviewing, leading, and guiding a customer discussion. 


Currently, best practices look more like this: they encapsulate both product dis- 
covery and engineering delivery. When discovery is applied the correct way, an 
entire product experience team can see the origin story all the way to the first, big 
idea stage. This involves the team creating the vision, strategy, and idea imple- 
mentation. These teams actually shape it. The delivery phase brings user experi- 
ence and product management to the engineering table. We have seen a lot of 
success using several different pieces of, or entire practices like Lean, slanted 
toward Kanban, Agile, and Scrum (see Figure 3-3 through Figure 3-8). This way, 
user experience and product management have the opportunity to witness how 
engineers size stories, how the single-piece workflow of a practice like Kanban 
breaks down into deliverables, and how much time it takes to deliver those 
story’s steps and details. The real goal here is for companies to make the journey 
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from inflexible products, processes, and platforms and grow into a constant state 
of assiduous iteration. 





Figure 3-3. Mitch Dumke (center) and team from Pluralsight leading a narrative session. Team 
members each jot down their simple narrative and then take turns to learn how each individual 
(engineering, product management, and user experience) sees the story coming together for the 
customer. Themes are collected and a simple narrative is created. 


SIZING 


oz) 5Meu=2 LJEEKS 


2.) Mepiua = | MONTH 


OATHS PUS 





A = 2M 
(ates) LARGE 


Figure 3-4. David Platt from Pluralsight (right) leading a priorities session with the team. On the 
far left are three separate taped artifacts resembling the personas they are creating outcomes for. 
The simple narratives are grouped into themes, then steps, and then details below. The team then 
sizes and creates cards for their Kanban boards. 
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Figure 3-5. One month’s worth of deploys at Pluralsight. Each box represents a story. 
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Figure 3-6. Directed Discovery includes both stages of continuous discovery and continuous deliv- 
ery. Column 1, VOC, stands for the “voice of the customer.” Column 2, CPT, stands for “cus- 
tomer preference testing,” or prototype observation. OE refers to cards dedicated to operational 
excellence. (Source: http: //bit.ly/2nzOXB6.) 
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Figure 3-7. One team’s worth of releases from October 2016. 
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Figure 3-8. A juxtaposition to a sprint cycle style of deployment. In most cases continuous discov- 
ery and continuous delivery are completely absent, potentially resulting in a higher frequency of 
rollbacks, bugs, and experience that don’t meet outcomes expected by the customer. 
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Power comes from the team seeing this entire process and learning its nuances. 
Nuances are by nature the small, easily overlooked ways of working together to 
create better outcomes. The team learns one another’s strengths and weaknesses. 
This approach also provides them with the opportunity to break apart and solve 
problems as a group so that everyone is part of the solution and they all see soft 
and hard skills working together. Teams that can relate to one another will also 
move more quickly and deliver at a blistering pace without even realizing it. To 
them, it is just a way of working. 


Better still, this approach embraces the idea of a fulfilled work/life balance, as the 
team is not operating at an artificial pace sometimes called “scrum theater,” 
which gives the illusion of productivity without the material impact. This situa- 
tion emerges when there’s a lot of activity but no clear metric is being created for 
measuring anything of value. If the team is merely following the process theory 
but not making true connections, then they’re probably going to fail. They will be 
going through the motions, but to any observer the team will look and feel soul- 
less. Velocity isn’t a label for ticking boxes on a spreadsheet; it’s what happens 
when there is authenticity and understanding in a team. In other words, velocity 
is not a measure of activity, it’s an outcome of good work. The team’s pace 
expresses their love for the craft of developing an amazing experience. 


DEVELOPING PRODUCT TEAM TALENT AND DESIGNING CAREERS 


Anyone in a leadership position at a product company would agree that people 
are their greatest asset. “Don’t forget that people make the stuff,” says design 
guru John Maeda. “Relations make the bigger stuff. Get the relations and people 
part right first. The rest will follow.” In the world of software creation, nothing 
comes close to the potential of great talent as a predictor of success. Unlike in 
traditional engineering industries, there are very few hard assets like machinery 
and inventory to evaluate. Almost all value in the creation of modern digital prod- 
ucts is the result of human capital. Time spent planning, discussing, designing, 
coding, selling, and marketing brings these products to life. Sure, there are the 
computers, cloud services, and physical offices needed to enable these activities, 
but they are all commodities and very rarely strategically critical to the success of 
a product. 


The challenge for product leaders is to be able to guide their people in a way that 
is both valuable for the company and for the individuals involved. We dislike the 
idea of humans as “resources.” They are not inventory. They are a company’s 
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greatest asset and should be treated accordingly. Taking responsibility for your 
team’s growth is a requirement for a product leader’s success. It cannot be out- 
sourced. Throughout this book you'll find suggestions and the recommendations 
of top product leaders for how to actively help your team members grow and 
develop. These suggestions are often stage-specific and contextual. What follows 
here are general recommendations that can be applied to most product organiza- 
tions and teams. 


Much like the processes of designing and developing product, the process of nur- 
turing product team talent is in flux. There is no generic solution to all organiza- 
tional challenges in this regard, but there are some best practices. One of them is 
Directed Discovery, which embodies human-centered product and design princi- 
ples where the user breaks the tie. Product leaders that have developed within a 
process like waterfall or even Agile will have to shift their mindset from a process 
to more of a work style with Directed Discovery. The distinct difference from 
those other approaches is that the team is completely autonomous, with account- 
ability built into the work style. Directed Discovery allows the team to see them- 
selves in a very objective way—that is, to clearly see their confirmation bias—by 
writing discussion guides, interviewing, building prototypes, iterating, writing 
code, and shipping a product with built-in analytics to measure whether the 
team’s qualitative research meets the desired outcome. The best implementa- 
tions are not overly structured but rather frameworks that provide guiderails and 
allow flexibility—a set of principles, not rules, that give leaders the foundation to 
implement their own growth models for their teams. The ideal framework pro- 
vides structure for daily decision making while still allowing for spontaneous or 
opportunistic adjustments. Even when you have a clear vision and a strategy to 
get there, it’s good to know you can course-correct when the right opportunity 
comes along. We call this work in developing the careers of team members 
“designing careers.” 


The first thing to recognize is that very few leaders are having the growth and 
development conversation with their team members. It’s surprisingly rare to see 
product leaders take the initiative in designing their team’s careers. Simply hav- 
ing these conversations will set a good product leader apart from the rest, and 
although the conversation alone won’t maximize the team’s performance, at the 
very least it will get them thinking about what it means to take control of their 
own futures. Applying design-thinking principles to one’s own life is both fun 
and satisfying. 
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Creating a career path to the vision 


If it’s not already obvious to those in leadership positions, your team will grow 
and develop with or without your input, but not in the way that helps satisfy any 
of the organization or product goals. If you have left a vacuum of opportunity, 
then other things will start to fill that vacuum. The problem you face as a leader 
is that any team member that cares about personal and professional development 
will seek growth opportunities in a way that’s not aligned with the organization, 
or even leave the organization to find support for their goals and dreams. Great 
talent won't tolerate an unsupportive or silent leader. If you’re not having the 
career design conversation, then the vacuum left by that oversight will be filled by 
someone else’s plans or ambitions. The outcome of ignoring this type of conver- 
sation is almost always negative, and losing good talent is often the worst-case 
scenario for any leader. 


It’s worth noting that designing people’s careers is frequently the best way to 
ensure that teams retain talent. You may have been led to believe that free 
lunches, ping-pong tables, and beanbag chairs were the way to do that, but that'll 
only get average talent in the door—and it won’t keep them. More than anything 
else, people want to be challenged, recognized, and respected. Sitting down to 
help your people design their careers is all about those things. Keep in mind that 
you’re not doing the career designing work for them, but you are providing guid- 
ance, support, and mentorship where needed. We’ll dig into the type of questions 
product leaders should ask of their teams. 


As the product leader, your role in helping to design your team’s career is very 
similar to how your design your product. The starting point of designing careers 
is to discuss the person’s understanding of their value, their dreams, and their 
vision for the future. Just like a great product, a clear, well-articulated persona 
and vision is a requirement for success. Clarifying your team member’s under- 
standing of themselves—the persona—follows a similar path as the one you'd 
use for a product user. As we’ve said, having your team members “eat their own 
dog food” (or the more palatable “drink their own champagne”) and do this per- 
sona work on themselves is a great exercise in self-awareness. Again, the tools 
common in product development can be used just as effectively on career devel- 
opment—the team becomes the indispensable product. 


BEING A GREAT PRODUCT LEADER | 57 


Starting career conversations with the big picture 


In his book Drive, and based on studies at MIT, Dan Pink suggests that to moti- 
vate employees who work on anything above and beyond basic tasks, we need to 
focus on three factors: 


Autonomy 
Our desire to be self-directed. As we’ve shown, this increases engagement 
over compliance. 


Mastery 
The urge to develop better skills. We’ll cover this in coming chapters. 


Purpose 
The desire to do something that has meaning and is important. 


The purpose provides a rock to which the activities that follow can be tethered. 
Don’t start career conversations with incremental improvements. As product 
leaders, we don’t start new product conversations by listing our feature require- 
ments. To get started, you need to know what problem the person is solving with 
their career. Understanding this is key to knowing how someone builds the path 
to a solution—that is, their career. Start with the why questions. Finding the pur- 
pose of someone’s career is the same as finding the purpose of a product. Here 
are some suggestions:® 


What dreams and plans do you have for your life? 
. Why these particular dreams and plans? 


. What is the problem you are working to solve? 


. Why is this a problem worth solving? 


. When you were an eight-year-old, what did you spend your time doing? 


1. 

2 

3 

4 

5. What does it look like several years into your career? 

6 

7. Why do you think those activities were attractive to you? 
8 


. Can you describe those activities in detail? 





8 We recommend you add to and edit these suggestions with your own ideas. Each organization and prod- 
uct culture will demand a slightly different approach. 


58 | PRODUCT LEADERSHIP 


9. How are they connected to your current work or career path? 


The last few questions are especially useful, because the activities that engage our 
young minds are often those that we have the greatest natural affinity for. Our 
favorite childhood games and activities are a great indicator of the things we’re 
attracted to throughout our lives, even when we're all grown up. Designing, mak- 
ing, building, and improving are just some of the qualities of play that might 
translate into a product team skill set. For example, a child attracted to creating, 
planning, and building things from scratch using whatever they have at their dis- 
posal—Legos or other components—might find similar satisfaction in building 
products as an adult. Reminding the team of the things that excited them in their 
childhood might help them identify what they want to do with their lives. 


Building a vision of your individual team member’s future isn’t always easy. It 
might take several conversations to reveal where their passions and skills inter- 
sect and for them to get clarity. Experience has taught us that it’s better to help 
them focus on what they love working on than on the specific output of that 
work. What hard work are they willing to do each day that gets them closer to the 
outcomes you both seek? What hard work are they prepared to struggle through 
to get to the other end? 


Rising above the trends and tech 


A key component of building the vision for a team member’s career is that it’s 
disassociated from time, technology, and trends. Having a vision that’s bound to 
the constraint of a technology platform is a problem because if that tech changes, 
then the vision loses validity. For example, a vision that states “I see myself being 
the best mobile developer in the world by 2020” is constrained to mobile tech- 
nology and to a timeline that the person has little or no control over. As quickly 
as mobile technology arrived, it can be replaced with something else. That leaves 
the career vision with either a confusing end or no value. A better expression 
might be, “I see myself as the most awarded creator of tech products that lever- 
age human’s natural mobility.” Removing the deadline gives the vision space to 
be realized sooner or later than planned and subsequently removes any stress 
associated with a timeline. This vision is also connected to something that’s con- 
sistent and valuable—human mobility. Technology that serves that quality can 
manifest in multiple ways. 
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Once the vision has been set, work together to describe the steps required to get 
there. To begin, have the person imagine they’re standing on the horizon, look- 
ing back at their present self and asking, how did I get here? The answer will 
describe the milestones along the way in broad terms. It’s not necessary to add 
lots of detail at this stage; these steps might be things like learning a new skill, 
meeting an important collaborator, joining a new team, or moving to an optimal 
location. Related to this is how your team member might take advantage of unex- 
pected challenges and spontaneous growth opportunities. This isn’t about 
responding to every new shiny object, but being aware of what’s going on around 
them and capitalizing on those things can support or amplify their plans. 
Unfortunately, we live in a time and work in an industry that sees people jump- 
ing from job to job, seeking the greener grass on the other side, and without a 
clear idea of where you are going, everything can seem like greener grass. Hav- 
ing a clear vision and guidelines to assess opportunities means being able to dis- 
tinguish between real opportunities and distractions. 


At the risk of repeating ourselves, we want to point out that these are similar 
approaches to successful product creation. A clear, timeless vision, supported by 
a set of guidelines to filter decisions and choices, leads to more predictable out- 
comes with more focus and less risk. Vision, values, and guidelines are effective 
decision filters. They help product people stay focused, and they help people 
focus their careers. However, without regular checks and constant nurturing, a 
career can easily fall prey to distractions. Developing a career vision and the ele- 
ments to stay the course will be worth nothing without some kind of homeostatic 
feedback loop. 


It’s also worth underlining that the idea of designing your career also applies to 
the product leader. 


Ultimately a product leader’s success is the success of their teams. If their teams 
are growing and developing in positive ways, it reflects on the leader. If the team 
is stagnating and unchallenged, the leader is almost always to blame. One of the 
measures of success is what is being delivered. 


Developing hard skills 


Mastering product management and design requires mastering a multitude of 
skills, and as we've outlined before there is no single degree or path that will 
teach your team all the skills they need in their role. This means the best product 
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leaders focus on continuously developing their teams’ skills, especially in 
response to the new ideas, requirements, or trends that will inevitably arise as 
your product and business develop. 


When it comes to hard skills, the first step is considering whether your team 
needs these new skills in response to a tactical need or a strategic focus. 


“If it’s tactical,” says Ellen Chisa, VP of Product at Lola, “such as figuring out the 
best way to instrument something you’re shipping next week, then you're just 
googling, calling someone, figuring it out; it’s pretty simple. But if it’s strategic— 
say you're at an early stage, you haven’t been thinking about revenue, and you 
don’t know how to do that—then that’s a very different problem. It’s really a 
spectrum for hard skills where you have to consider what are we trying to do 
here, what are we trying to learn, and what’s the most effective way to learn that 
going to be?” Also recognize that everyone in your team learns differently, 
whether it’s just googling things or needing the structure of a formal course or 
class. 


Developing soft skills 


Soft skills, such as managing people, communicating clearly, and empathizing 
with other stakeholders or customers, are by their very nature much, much 
harder to teach. The best way to handle these skills is to use a coaching approach 
where you focus on one skill at a time and coach the team member whenever 
that situation comes up. Ellen Chisa underscores this point: “The most impact 
I’ve ever seen on coaching soft skills is being able to come up with an example 
right after it happens and pull someone aside and say, ‘I noticed in the meeting 
you did this. What were you trying to do with that?’ Sort of coaching it in the 
moment.” 


Balancing Discovery and Delivery 
There is nothing quite so useless as doing with great efficiency some- 
thing that should not be done at all. 
—PETER DRUCKER 
Optimizing teams and processes for delivery is a practice that is deeply rooted in 


software engineering. Some of the most widely known delivery practices are 
Agile, Scrum (which lives inside Agile but has been more of the focus in recent 
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years), waterfall (better known as the grandfather of early software practices), and 
finally, Lean. These broad buckets have their own subcategories. For example, 
within Lean is Kanban, a widely practiced byproduct of the Toyota Production 
System (TPS). All of these well-respected frameworks, processes, and workflows 
have been the guardrails within which we have all worked in the modern era of 
software development. A multitude of documents, products, tools, and the like 
have all been created to articulate what they mean to different companies and 
humans. 


Process aside, as we’ve outlined earlier, the biggest delivery challenge is deciding 
where to spend the resources you have. We’ve discussed prioritization in depth, 
but how do you know what should even make it to the table for consideration? 
It’s extremely hard to know whether to add new features or improve existing fea- 
tures. This gets to the heart of product leadership. How does a leader juggle the 
available resources to align with the customer’s needs? Especially those needs not 
yet met. Simply because customers are using a product does not imply that they 
are enjoying it or even like the product. “That’s probably a pretty common mis- 
take people make when working in product,” says Marco Marandiz, Product 
Manager at HomeAway. A product manager or leader can be fooled into believ- 
ing that because people are using their product, it doesn’t need any improve- 
ment. Marandiz argues that product leaders will say to themselves, “People are 
using it, so it must be scratching their itch,” but that this would be a mistake. 
Instead, they should be asking, “How do I make this more relatable to other peo- 
ple? How do I reposition or frame my product in a way that addresses more peo- 
ple’s issues in a way that is actually valuable?” Discovering new problems or 
improving on existing problems boils down to the effort you put into understand- 
ing your customer. Great product leaders spend the majority of their time focus- 
ing on this discovery process. 


PUSHING PIXELS VERSUS PUSHING THE ENVELOPE 


Product managers might be inclined to focus on the updates to the UX or UI 
because that’s very often easier to do than understanding the customer. But ask- 
ing your customers which UI elements need to be changed will get you only a 
fraction of the information you need to make a product better. Discovering the 
real reasons customers use your product will leapfrog the basic interaction ques- 
tions and go straight to the core of why they think it’s valuable. This perceived 
value is where the attention of the product team needs to be. “I would say, take 
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more time to make sure you’re asking the right questions, and use the data to 
find the real answer,” says Marandiz, who feels that focusing on data alone is a 
common distraction for product people. “Data is very valuable, but isn’t helpful 
without qualitative research. You need to ask the right questions. You need to 
really understand who’s using it and what you are not fulfilling as much as what 
you are fulfilling.” 


This process of digging deeper into the value of the solution you’re seeking 
strikes the balance between discovery and delivery. Discover for value and then 
deliver on that value. Use your product vision as a lens to focus your discovery, 
but use the qualitative feedback from your customers to refine what you deliver. 


Qualitative data is best gathered when you have something to share with your 
users. Prototypes, and the observations that go along with sharing them with 
users, are exceptionally powerful ways to gather this data. As John Maeda, Global 
Head of Computational Design and Inclusion at Automattic and previously 
Design Partner at Kleiner Perkins Caufield & Byers, says, “If a picture is worth a 
thousand words, a prototype is worth a thousand meetings.” We recommend 
reading Design Sprint: A Practical Guidebook for Building Great Digital Products 
(O’Reilly) by Richard Banfield, C. Todd Lombardo, and Trace Wax? for more 
information on how to create prototypes and develop the interviewing skills 
related to gathering qualitative feedback. 


MAKING DISCOVERY PART OF YOUR PROCESS 


The key to successfully making discovery a core part of your product develop- 
ment process is to make it a regular part of your process, one of the rituals you 
do alongside stand-ups, retrospectives, and the like. The best teams we’ve spoken 
to make discovery and customer research a regular commitment—whether it’s a 
day per week or once per month. Even if they don’t always have something new 
to show, this schedule ensures an organization’s commitment to constantly 
learning and discovering what their customers value. Discovery is a muscle, and 
you'll only stay strong by using it regularly. 





9 Richard Banfield, C. Todd Lombardo, and Trace Wax, Design Sprint (O'Reilly). 
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Just Enough Process 


On the practical methodology side of product leadership, there is also a lot of 
confusion, as well as discussion, about what processes to use. Every good product 
leader understands the need to be customer focused and iterative, but many are 
not quite sure what that looks like from a day-to-day process point of view. These 
are some of the questions they ask: Do we use Agile? Scrum? Are we Lean? Are 
we Lean-UX? Are we a hybrid of Agile and Lean? Do we even need a process to 
be successful? Are we a combination of those things? Are we just making it up 
on the fly? These questions often overlook the fact that the specific tactics of 
these methodologies and frameworks have never been proven to substantially 
improve a product’s success. 


So how does a product leader select the best process? Because these questions 
can be answered only in the context of the organization’s history and current 
implementations, it’s ridiculous to suggest a single solution. What the leader 
needs to do is understand the specifics of their organization and choose a process 
based on that information. Every company and team has a different culture, and 
that culture informs the best option. Here’s a list of questions the product leader 
needs to ask to select the ideal process for their organization: 


1. What is the process problem we’re trying to solve? 


2. Do we really know if this is the right problem to be solving? 


w 


. What assumptions have we been making that should be tested or valida- 
ted? 


. How will we test a new process? 
. What’s our hypothesis? 
What metrics will we measure to prove or disprove our hypothesis? 


. Who are we building a product management process for? 


. Will these proposed changes dramatically improve the value of what we 
are delivering? 


9. Will these proposed changes make the lives of the team better or worse? 


10. Are we considering these changes because of external pressure or because 
we can truly justify the improvements? 
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11. What will be affected if we add, change, or replace the current model? 


12. If we chose to add, change, or replace the current model, what will be the 
best way to make this happen without losing good talent or disrupting the 
delivery of value to our customers? 


This list is not exhaustive because each organization will have industry- and 
stage-specific nuances that we can’t know from the outside. What these questions 
do is help the product leader think through issues facing the organization before 
changing or disrupting the current process. The goal is to understand what the 
digestive system of the organization looks like and what it is able to digest on a 
day-to-day basis, then plan for that. 


The big insight is this: process means nothing without a great team. A mediocre 
process can be reformed into an excellent process by great people, just as a 
mediocre team can undermine even the best process. Choose the team first, and 
then decide what process amplifies their best efforts. 


There is also the issue that companies of different sizes need different 
approaches depending on which growth stage they are in. A business can go 
from being a startup to an enterprise in less than a decade. That growth creates 
massive friction for both people and processes. We’ve interviewed and worked 
with a wide array of companies, and it’s not uncommon to see inconsistencies in 
even the most established ones. Just as small companies aren’t always agile and 
fast, fast-growth companies don’t always attract great talent, and big companies 
sometimes can’t plan ahead effectively, despite all the resources at their disposal. 


Even in today’s fast-product timelines, some teams don’t have daily iterative 
cycles. That’s just not part of their cultural fabric. A great product leader needs to 
be aware of these inconsistencies and be able to plan accordingly. There are other 
teams that work at such high velocity that they operate on intra-day cycles, fre- 
quently prototyping and testing, not in the traditional design sprint five-day 
period, but in a three-day, or even two-day, period. To get on board with this and 
make a difference, the best product leaders have to be empathetic to the organiza- 
tion and the teams, and adjust themselves accordingly. 


Our advice for product leaders is to spend as much time understanding the team 
culture, problems you’re trying to solve, and the specific organizational context as 
you do identifying the best features for your product process. Having smaller, 
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cross-functional, collocated teams that have autonomy to select the best process 
for their specific needs might be the best solution of all. 


Today’s industries and environments shift so fast that it’s hard to know anything 
for certain, and for product leaders around the world, that means going for a long 
swim in the sea of ambiguity every morning. They’re searching for the rigor of 
process, but it can’t always be found. As leaders, we need to understand that the 
rigor is not going to come from the process, but from an understanding of the 
context and the team—something that takes a lot of effort. For these reasons, 
product managers might be feeling a bit out to sea and are looking for help to 
find some solid ground. They want to be recognized as people who’ve got persua- 
sive power over what happens to the product they are building—even if that rec- 
ognition comes at the expense of authority. 


Communication and Constraints 


Connecting how you communicate to how people experience you becomes a big- 
ger issue when you have constraints—for example, if you are under pressure to 
deliver on a deadline, or have an unrealistic expectation placed on you from 
another party. External and internal constraints are unavoidable and necessary 
for growth and improvement. 


Understanding product leadership constraints requires first understanding your 
influence within a team or company. Whether you realize it or not, people hear 
every word that comes out of your mouth. Some of those people hang on every 
word you speak or write. What you say determines what your team sees as possi- 
ble or impossible. Language is the point of creation, whether it be written, verbal, 
or body language. Your team picks up on those cues. Teams beyond your imme- 
diate responsibility will also be influenced by what you communicate. Training 
yourself to listen, to watch your words, and to consider the way they are received 
gives you an awareness that will make your communication more effective. Lan- 
guage either breaks down or enforces certain constraints. The specific words you 
use communicate constraints that, up until the moment they are received, may 
or may not actually exist. 


Let’s consider how this works in product teams around the world. All product 
teams have to solve problems. Each day those teams discuss the problems. Many 
product leaders trying to deliver on a certain product experience talk about the 
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options for solving those problems. Leaders might say things like, “These are the 
resources we have to throw at the problem,” or “We only have so many resources 
to go around,” or “We can’t hit that date with this much notice!” When a leader 
starts a problem-solving process by directing their team to certain options, they 
are shutting down the creative process. Leaders who are describing these con- 
straints are not deliberately restricting creativity, but that’s often the outcome. 


Step back for a minute and think about phrases like the examples just given. 
Those points of view suddenly become really limiting, yet how many times have 
we uttered them to teams and leaders around us? By using language like this, the 
leader creates restrictions to potential solutions. And when presented with such 
limited options, the team may assume the leader wants them to ignore all other 
options, even those not yet discussed. The team is not at fault here. They are 
doing what the leader has asked of them. When people hear limits, they don’t 
experience inspiration, creativity, or leadership. 


As fellow product leaders, we know that you can come up with a lot of reasons to 
justify why these options are a reality for you. For instance, you could be protect- 
ing teams because they are already under a lot of pressure. They have too much 
on their plates or, in some cases, those options are the only known reality. Justifi- 
cations tend to be based on the illusion that leaders need to have all the answers. 
If you, or your organization, defines leadership as having all the answers, then 
you’re misunderstanding leadership. Leadership is empowering people around 
you to see the vision, strategy, or a mission. The job of the leader is to be connec- 
ted to the why of the work, not the how. Let teams shape the how. If you are a 
product leader playing deep in the how of the work, then there’s a very good 
chance your people are struggling to know what to do. Free yourself from the 
mental constraints of just giving options to people, and focus on the problem 
statement. Once you've got clarity on that, you can pass the responsibility of solv- 
ing the problem onto your team. 


You are the leader of a team, or possibly several teams. How you organize them 
around what is currently most important is your job. It follows, then, that giving 
them the best possible language to empower them is also your job. We’re not 
talking about motivational speeches. We’re talking about using a common 
vocabulary that shows your team you trust them to come up with solutions on 
their own. A common set of terms and descriptions goes a long way to remove 
assumptions about what you expect from your team. This goes beyond just 
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describing artifacts and processes, but giving them meaning too. A task or arti- 
fact without a clearly communicated meaning won’t have the impact you seek. 
For example, it’s not uncommon for members of a team to disagree on what a 
term like wireframe means. Is it a high-fidelity or low-fidelity artifact? What for- 
mat is it delivered in? Does the wireframe need annotating? Why do we need the 
wireframe in the first place? Who benefits from this activity or artifact? 


Communicating this outwardly is necessary to build the trust that makes good 
teams great. Center your teams on the why as a way to frame the best solutions. 
Think back to conflicts you may have had over direction with your peers or teams 
reporting to you. Most of these stem from the language you or others created. It 
is your job to create language that moves the constraint to a new dimension of 
possibility. Treat this like a practice. Take time to learn how to do this. It may 
take months or even years. Commit to making it a daily exercise and teaching it 
to your team. It will take some time to settle in, but the fruits of this effort will 
return a tenfold value. 


Clarifying the Question of Authority 


The scarcity of recognition for their work can be a hard pill for product leaders to 
swallow. Many of the product leaders we spoke to mentioned that there is far less 
recognition for their team’s work than they had anticipated. In some cases, they 
may have come from roles where this was a part of the leadership environment, 
only to find themselves in a situation where recognition—from their company 
peers and the market in general—is rare, or even nonexistent. Product leaders 
are like the Aquaman of the technology world; they’ve been told they’ve got great 
superpowers, and they get to stand side by side with all the other superheroes, 
but they’re still not getting the respect they feel they deserve. 


This may seem like rubbing salt into the wounds of an already difficult job, but 
it’s unlikely that the product leader will ever get the same personal recognition as 
other positions. Despite this, they do need some recognition for the hard work 
they do within the organization, or they might begin to feel undervalued. One of 
the ways to foster this is to create teams of people who value each other so that 
respect and recognition come from within. 


As we mentioned earlier, the role of product leader often feels like all the respon- 
sibility without all the authority. This should not be interpreted as never having 
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any authority. Creating strong and successful teams is almost always in the 
power of the product leader. Product managers may not share this authority, but 
it’s rare that a senior product leader doesn’t have the influence and direct author- 
ity to hire their teams. The subtle difference is that product leaders don’t neces- 
sarily have authority of the entire company or over tangential teams. The 
founder-as-product-leader does have authority over the wider team, but that 
doesn’t mean they should rely on it; they should still lead, not command. Non- 
founder product leaders also have the authority to hire their product managers 
even though they don’t have hiring or general authority over the rest of the prod- 
uct team (design, engineering, etc.). 


Managing Politics 


Leaders must find a way to depoliticize the normal work process and give their 
teams the superpowers to be successful. By giving them “superpowers,” we mean 
help them to amplify their impact. In other words, build tools and habits that 
highlight their impact beyond the average. Empowering teams can generate the 
recognition that all human beings crave. When these amplifying habits and 
behaviors are put into practice, the product leaders and their teams can go back 
to their stakeholders and say, “Look at what we’re doing. Here is the impact 
we've made.” Whether they're artifacts, demos, prototypes, or actual finished 
products, it doesn’t really matter; results have to be shared with the organization. 
If leaders are looking for ways to bolster their internal influence and authority, 
they must see this as part of their jobs. 


To be clear, this should never be selfishly motivated. Seeking recognition in these 
practical ways allows product leaders to develop authority and then use it as lever- 
age to develop more influence within their organizations. 


ls There a Formula for 
Success? 


K 





4 
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The primary concern for product leaders, and the people that hire them, is what 
makes a successful product leader. Closely related to this is how the leader builds 
a successful team around them. From the very first interviews with product lead- 
ers, we felt sure that a generic description of a successful leader would prove to 
be nothing more than a myth. No two product organizations, not even close com- 
petitors, are alike enough for a cookie-cutter approach to be possible. Certainly, 
no product leaders are that alike either. 


It’s not surprising, then, that there is no single formula for success. Despite this, 
we were excited to find common threads running through the characteristics and 
styles of successful leaders. For the old pros, they will be reminders of what’s 
effective; for the newcomers, they'll be a collection of best practices to amplify 
and accelerate personal growth. Here are some of the topics we'll cover in this 
chapter: 


e What works for other successful product leaders 
e What styles of leadership exist and which are applicable to you 
e What insights are generic or transferable across organizations 


e What mistakes product professionals commonly make, and how they can 


be avoided 


What Does Product Leadership Success Look Like? 


Success as a product leader can be hard to define, but it is critical to do so cor- 
rectly and to consider not only the leadership, but the product too. Ultimately, 
each product, company, and sector will be judged differently. Their successes and 
failures will be relevant only in the context in which they exist. However, one 
thing is certain: a product leader will be judged by how well they deliver a valua- 
ble solution to a customer problem. 


This resonates with our own experiences and was reiterated by our interviewees. 
The bottom line is to focus on the problem. As GV’s Ken Norton says, “I like to 
start with the problem. Smart people are very solution-oriented, so smart people 
like to talk about what the solution is going to look like to the problem. But suc- 
cessful people think about the problem. Before I talk about this product, or this 
feature, or this device I’m going to build, I must understand the problem at a 
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deep level. Then success is easy to articulate, because you know what it’s like 
when that problem is solved.” 


Framing your success around solving or ameliorating a customer problem makes 
it much easier to define, share, and communicate that problem with your team. 
Suddenly, finding ways to get to that successful end state becomes much easier. 
The best product managers, therefore, focus on defining and prioritizing prob- 
lems, not solutions. 


Focusing on the problem instills a sense of what the goal is before it’s even 
articulated. The team focuses on the user’s need—what you're trying to solve and 
why you need to solve it, not how. The research automatically skews toward a 
deeper understanding of the user, instead of simply testing possible solutions. 
The user stories and personas become rich background information, which helps 
everyone involved make connections and find solutions that might not otherwise 
be obvious. By avoiding optimizing for one possible solution, focusing on the 
problem and describing it well to the team can open up a much wider universe of 
solutions. Once the research has been done and defined, and the problems 
described and prioritized, the delivery team can collaboratively design the solu- 
tion that gets the job done most effectively. That way everyone’s creativity can be 
directed toward a much better result. 


Measuring Success 


The best product leaders have a considered approach to defining and measuring 
success. Paul Adams, VP of Product at Intercom, says, “We spend a lot of time 
defining the problem and defining the success criteria. What’s the problem we’re 
going to solve and how will we know if we solved it?” 


Measuring success will always be a hotly debated topic in the product leadership 
world, because we are all looking for an elusive metric that isn’t universal. There 
are so many debates about NPS (net promoter score), daily active users, licenses, 
LTV (lifetime value), and engagement by event. Our hope is that the develop- 
ment, product, and user experience roles are beginning to see the problem that 
has been distracting them from making clear decisions—outputs versus out- 
comes. Because we have been so focused on engineering delivery, our success 
metrics have been based on the output of simply shipping an experience to a cus- 
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tomer. It’s time to go beyond the output and think deeply about measuring the 
outcome. 


“Good product leaders think about success in the short term and the long term. 
If anything, they’re thinking more about the long term than many other people 
around the table,” Tanya Cordrey, previously Chief Digital Officer at the Guard- 
ian, underlines. 


Here is a great example that hopefully we can all relate to. Imagine an enterprise 
dashboard that is intended to show return on investment to the buyer of an 
enterprise solution. In the planning phases, the requirements are set, and a beau- 
tiful interface is designed, coded in the web application, and shipped. Typically, 
the fact that something that the user hadn’t had exposure to has been shipped is 
success enough. This is not true anymore. The best product leaders in the world 
are placing a big data layer between the design and the server side, so they are 
able to measure every affordance choice in the experience. An example of an out- 
come in this scenario would sound more like this: 


We would like to see a 65% increase in engagement of our enterprise 
dashboard experience within a 90-day period of production release. We 
would add in additional key performance indicators (KPIs) like average 
time in app, increased average # of logins. We also believe that these 
design bets (affordance choices within the experience) will drive that 
growth. 


Normally, this would be established in the discovery phases and become the sole 
reason for creating a new innovative experience, refreshing an old experience, or 
removing technical debt. You can use other indicators such as NPS, which has 
proven to be a very scalable, teachable, and useful metric to use when applied 
correctly and not used as the only metric. 


Cordrey adds, “I think return usage or any measure of customer satisfaction and 
loyalty are really important, because I think we’ve seen in the history of the inter- 
net that there are many companies with incredible topline figures, but at the end 
of the day those companies stall because they don’t have any retention and they 
can’t hold on to their users.” 


Most metrics suffer from this—a single point of measurement. Try to begin with 
establishing an outcome, not an output, and that outcome should be based on 
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your customer and the problem you are trying to solve. Then use several metrics 
in the experience to measure that outcome so that you don’t rely on a single met- 
ric organization-wide to drive your product strategy forward. The results will 
speak for themselves. Actionable, measurable, and time-bound metrics that bal- 
ance the short term and the long term are the best practice by the world’s best 
practitioners. 


Measuring Success as a Problem-Solving Ability 


Recognizing product leadership through the use of measurable performance 
indicators is only the first part of the story. The second part is the organization’s 
ability to measure success. This, ultimately, is the ability to measure the problem 
statement, and that is as important as defining the problem itself. Many product 
leaders fall into the trap of measuring success with exclusively internal metrics, 
like how many cards were shipped. They assume that the announcement “We 
shipped!” releases tension from the team, because they assume success is meas- 
ured when the item is delivered. This couldn’t be further from the truth. We 
agree that having an efficient delivery model that ensures work is shipped in a 
reasonable and healthy manner is a form of success, but, if the only motive is to 
ship an artifact, then it doesn’t solve the problem. Shipping work must also solve 
a problem and result in customers truly receiving value from whatever was 
shipped. It follows, then, that the ability to measure the outcome of this is para- 
mount. It would be better to see teams obsess over indicators of success or fail- 
ure as they relate to solving the identified problem statements. 


Pluralsight, an online learning platform, provides a great example of this with 
how they discovered a problem statement around note taking: 


Through observing Pluralsight’s learners [the company’s internal name 
for users], the team noticed two behaviors which proved to be important 
indicators of future improvements. While watching the Pluralsight cour- 
ses, one learner was observed jotting down notes on a physical notebook, 
while another did the same using sticky notes. The learners wanted to 
save information they thought was important so they could return to 
those spots at a later date, and the handwritten note was a timestamp or 
a couple of words intended to jog their memory. These observations by 
the Pluralsight user testing team identified a problem that eventually 
became a permanent notes feature. The fascinating thing for the team 
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was that the competitive landscape for this scenario was not another 
product, but a notebook and a sticky pad. 


The team in this example rallied behind this problem statement. Once they 
released the feature into production, they began tracking a number of interac- 
tions with it versus other popular affordances to get quantitative feedback. The 
team was also acutely aware of the qualitative feedback that helped them make 
informed decisions on impact and next steps. 


Success is a function of a team’s ability to unco.ver a problem, see how that expe- 
rience would empower the user if it were gone, and deliver the solution in a 
delightful and efficient way. 


Common Characteristics of Successful Product Teams 


Every team has a unique set of characteristics that bonds its members and aligns 
their efforts behind shared goals. However, it is possible to identify common 
themes in successful teams, and in our conversations with top product leaders, 
these came up again and again. Unsurprisingly, not one of our product leaders 
mentioned hard skills, such as engineering, design, or specific product manage- 
ment expertise. On the other hand, soft skills were referenced by almost every- 
one. In Drift cofounder and CEO Dave Cancel’s words, “It’s not that the [product 
leadership] skills are secondary; it’s that their past experience is secondary.” Can- 
cel believes that the characteristics of a successful product leader will always be 
weighted toward the softer skills. “What we’re looking for are things that fit more 
on the qualitative side, which people hate because it’s so squishy.” These “squi- 
shy” things, when present, are what makes the people management element of 
the job infinitely easier, and they tend to be found in all great product leaders: 


e Lifelong learning. Actively seeking new information, insights, and under- 
standing is a cornerstone to successful product management. Things 
move fast in software, and standing still is consummate to sliding back- 
ward. Connected to this is an open-mindedness and coachability in all 
respected leaders; they don’t assume they know all the answers and con- 
stantly refactor their thinking to take in new knowledge and feedback. 


Strong communication. This is a big bucket that includes several soft skills 
like listening and presenting, but communication is fairly self-explanatory. 
As Bob Allard, CEO of ExtensionEngine, says, “All project management 
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problems are communication problems.” This can be extended to product 
management too. Strong leadership of any kind has a foundation in strong 
communication skills. 


Empathy. Deeply connected to communication is empathy—not only 
empathy for team members inside and outside the organization, but for 
customers as well. “I think [product leadership] is significantly customer 
focused, and needs to be in order to build a great product,” says Joshua 
Porter, founder of Rocket Insights, a Boston-based product design and 
development agency. Nothing exists without the customer, so empathy for 
the customer experience is essential. Another element of empathy is being 
sensitive to the product creation environment you’re working within. This 
environmental empathy gives the product leaders insight into the kind of 
team to build and how that team can be aligned with the larger organiza- 
tional goals. 


Diversity. Strong leaders know that a diversity of backgrounds, experien- 
ces, and demographics provides the range of perspectives needed to build 
a complete product experience. A one-dimensional team will produce a 
one-dimensional product, and the modern software product space is a 
complex array of tastes, needs, and expectations. Top product leaders look 
for team members that can bring differing opinions and experiences to the 
table. 


Business savvy. This characteristic is related to how product leaders under- 
stand their role in the value delivery process and their grasp of the broader 
business context. Solving problems for your market is the primary reason 
for the role, and a strong knowledge of where to focus effort and manage 
the assets to ship product is essential. It’s not necessary to have a full 
range of financial and operational skills, but a good product leader needs 
to be able to take a seat at the executive table. 


Cross-functional representation. Teams without representation see the 
world with strong biases. The more a product leader can bring the func- 
tional areas of a product together, the more likely the team will act in a 
coherent manner. 


Collocation. Working side by side with your team makes communication 
easier and faster. Placing the product manager next to the product mar- 
keter can have striking results on improving feature release communica- 
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tions. We really want to emphasize that the teams should sit right next to 
each other when possible. This improved communication substantially 
increases a company’s building velocity. 


e Autonomy. The best teams have the ability to solve problems on their own 
without having to run everything up the ladder. Decision-making skills 
and the authority to implement those decisions are critical to a team’s 
speed and effectiveness. 


e Interdependence. This might seem almost contradictory to the autono- 
mous point, but successful teams don’t wall themselves off from the rest 
of the company. Autonomy is a reference to the ability to make decisions, 
not a reflection on their avoidance of others. Seeking out others in the 
company for input and knowledge reflects maturity in a product team. 


e Accountability. The best teams place guardrails in place that allow them to 
see clearly when either the qualitative research isn’t paying back or the 
product releases are not hitting the desired outcomes. These guardrails 
must be supported by metrics and frequent measurements to be meaning- 
ful. Having these in place acts as insurance. Teams appreciate having this 
real-time feedback loop. As you can imagine, upper management also ben- 
efits from having this in place—especially in the early stages, as it estab- 
lishes trust. 


There are other characteristics that product leaders seek in their teams and 
organizations, but these consistently top the list. The more specific the product 
team roles, the more specific the skill set will be. For example, a product man- 
ager who is working on a product that leverages design aesthetics is likely to have 
a good sense of taste. Leaders will seek the team skill sets that match the context 
and stage of their product. 


How to Identify Product Leaders 


If you’re a hiring manager, team lead, or a startup founder, you'll need to know 
what constitutes a good product manager. Hiring for product leadership is hard, 
and the difficulty is exacerbated by the current high demand and low supply in 
most markets. The product leadership role will always include hiring and manag- 
ing people, so unless you're a single founder in a very small startup, you’ll be 
working with others, some inside and some outside the company. They might 
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not be directly reporting to you, but you'll be collaborating with them. Either way, 
working with people is part of the job. Although we’ve already mentioned some 
hiring strategies and tactics in earlier parts of this book, this section deals specifi- 
cally with what to look for in a product leader. The characteristics listed earlier 
are high-level and provide some guidance for founders and hiring managers. 
This section digs a little deeper to describe what leaders should look for in high- 
performing product team members. 


We've listed several areas that successful leaders point to when hiring a team or 
looking for product leadership in their organizations. Every organization will 
have qualities specific to that culture or situation, but the following qualities are 
relevant to almost every product manager and team. Some characteristics may be 
more relevant than others depending on the product, company culture, and stage 
of the business, but in general a good product leader: 


e Plays well with others. Product management and product leadership are 
people-first roles. Teams are made up of individuals who each bring their 
own personalities, perspectives, and opinions. The best team members 
understand this and embrace the diversity, investing in getting to know 
one another. Understanding what makes people tick makes it easier to get 
the best out of them and identify when there is a problem. It has the added 
benefit of opening up communication channels. The personalities we 
exhibit at work are generally guarded and often belie our true nature, so 
taking the time to talk to one another provides the opportunity to commu- 
nicate directly and honestly. Beware of the talented engineer who insists 
on working independently and claims to work better when left alone. Pro- 
viding quiet spaces for people to work in can be productive, as long as 
team members don’t become isolated and shrink away from others, which 
can lead to misunderstandings and a breakdown in communication. Great 
product people see their work in the context of what the team is achieving. 
They are capable of connecting and communicating with lots of different 
personalities. This does not mean they are all things to all people, but 
rather that they are able to engage empathetically with others, even when 
they don’t have a lot in common with them. 


e Seeks challenge. The product leader that enjoys new challenges will thrive 
in the current digital product environment. Between the ever-changing 
technology and product markets, there is never a dull moment in this 
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space. Being comfortable with the ambiguity of this role is something we 
observed in most of the product leaders we interviewed. There are chal- 
lenges around every corner, and a strong leader tends to anticipate change 
and prepare their teams for the constantly shifting sands of this space. Set- 
ting the expectation that nothing will remain the same reduces the stress 
that arises when that change inevitably happens. When hiring, ask ques- 
tions about the person’s experiences dealing with challenging situations. 
Candidates should get excited and animated about how they solved prob- 
lems or the prospect of meeting challenges head-on. 


Gets their hands dirty. Anyone who has worked on a product team knows 
that things are never perfect. The best team leaders don’t shy away from 
the daily messes; they get their hands dirty and solve problems. “I get feed- 
back from the people I work with, that, as a vice president, I do a lot of 
practitioner-type work,” says True Ventures Design Partner Jeff Veen. 
“And I don’t mean sitting at Sketch or Photoshop with the pixels, but I run 
a daily stand-up with the teams going through what the decisions are for 
each day, asking, what is the product going to be? What did we find out 
from the usability testing?” Helping make tough daily decisions can be the 
best way for product leaders to help their teams. As Veen suggests, getting 
your hands dirty doesn’t mean doing the work of the technical members of 
the team. On the contrary, a poor manager or leader is constantly jumping 
in to do the practitioners’ work because they think they can get it done 
faster. Trusting others to get their work done is more effective, and dele- 
gating is the goal; this doesn’t mean being absent, it means involving your- 
self in the day-to-day workflow so you know what’s going on and can assist 
where necessary. Showing up as an experienced practitioner, but not feel- 
ing like you need to push the pixels or write the code, is a healthy balance 
for a leader. What this means is that leaders do need to remain close to the 
practice of the product creation process to ensure they maintain credibility 
with the team. Ultimately, unblocking obstacles from the flow of work is 
the best way for a product leader to get their hands dirty. 


Always acts and thinks “team first.” The kind of leader that needs constant 
recognition and praise is not likely to be the best person for this job. The 
top product leaders hardly ever get recognition for their hard work and 
dedication. Furthermore, they tend to turn any limelight they receive back 
on their teams. Putting teams first is what leaders do at all levels, and espe- 
cially at the product level. Their efforts are consistently put through the 
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lens of, “What can I do to make my team successful?” Knowing what will 
make the team successful, and acting on that, should be a part of a leader’s 
daily work. This team-first approach also relates to how leaders motivate 
and incentivize their teams. OKRs, goals, or rewards should all be aligned 
with what the team is working toward. This does not discount individual 
growth plans and OKRs, but they should be aligned with the greater good 
of the team or company. Culturally healthy companies will align individual 
and team goals with the company vision and values. Immature or unheal- 
thy cultures align their team’s goals exclusively with things like financial 
bonuses for senior executives, share price, or the investors’ exit event. 


Is comfortable wearing lots of hats. All of the product leaders we inter- 
viewed have very diverse experiences and career paths. They are comforta- 
ble wearing the hats of marketer, manager, technologist, customer 
advocate, and facilitator, to name a few. We should add that this doesn’t 
mean they are experts at each of these roles; rather, they are comfortable 
working across all areas as the role evolves or as the product demands. On 
the downside, this can be a weakness if the product leader tries to fulfill 
too many roles for extended periods. Being competent doesn’t mean they 
have to take on everything. Understanding their own weaknesses, so they 
can delegate to more skilled team members, makes product leaders even 
better in the areas where they are strongest. 


Displays curiosity. This trait relates to several others mentioned here, but 
needs to be addressed specifically. Having a deep interest in learning, 
enthusiastically accepting new challenges, encouraging others to speak up, 
and listening to their perspectives are all actions driven by curiosity. Curi- 
osity gives leaders the necessary mindset to solve problems. Product lead- 
ers are constantly reading and learning about what’s new and what will 
affect their product and teams. A leader that’s less curious is likely to miss 
potential solutions. Product leaders on the other end of this curiosity spec- 
trum have little or no interest in other’s viewpoints, in listening to custom- 
ers, or in learning new skills. This closed mindset tends to shut them 
down to new opportunities and solutions. 


Communicates well. This might seem so obvious it’s not worth mention- 
ing, but it’s surprising how many senior managers and leaders are poor 
communicators. Having the ability to share information in a clear, concise 
manner is a necessary and desirable skill for a product leader. Whether 
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they’re talking, listening, writing, planning, sharing, or facilitating, the 
goal is always to be understood. Key amongst these is written communica- 
tion. Much of the product leader’s time is spent writing documentation, 
emails, reports, and messages to the team, outside partners, and other 
company leaders. If writing isn’t a strong skill, then getting training, or at 
the very least having a skilled assistant, is recommended. Visual communi- 
cation in the form of sketching, drawing, and mapping is also an effective 
skill for all leaders in the modern era of whiteboarding and collaboration. 
Product leaders can be found at the whiteboard or sketchpad sharing their 
ideas on problem solving several times a day. Developing these skills helps 
tease the concepts out of the team’s minds and onto a space where those 
ideas can be shared and discussed. Even if stick figures are the pinnacle of 
their drawing abilities, it’s still an important part of the leader’s communi- 
cation repertoire. 


Possesses selling skills. This might be controversial, but when you con- 
sider what product leaders do each day, it’s no surprise that selling is on 
this list. To be clear, this is not the type of selling associated with business 
development; rather, it’s the type that works to change minds and get buy- 
in from others. In his book To Sell Is Human (Riverhead), Daniel Pink 
refers to this skill as the ability to “move” people from one mindset to 
another. Product managers and their teams spend several hours each day 
engaged in these activities. They collaborate with each other to move ideas, 
and this requires being able to sell concepts and advocate for perspectives. 
Many leaders we spoke to don’t even realize they are selling, because get- 
ting buy-in on ideas feels like part of the job; however, they all recognize 
that these skills are critical to effective leadership. Linked to sales skills are 
negotiation skills. This is evident to any product manager who has had to 
present a project plan to an executive team. Life is one long negotiation. 
Every interaction is an exchange of sorts. Unfortunately, negotiation skills 
are not always natural or inherent. In fact, most people find negotiation 
difficult and even distasteful. Learning how to get what you need for your 
team to be successful means learning how to negotiate, and for any prod- 
uct manager, it might be worthwhile to get some training or coaching on 
this topic. At the very least, read the book Never Split the Difference: Negoti- 
ating As If Your Life Depended on It, by Chris Voss (HarperBusiness). 


Has exceptional time management skills. Shipping product is a race 
against time. Managing that race is a series of little decisions that collec- 
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tively make up the product roadmap. Product managers that have risen to 
be leaders know this and protect their time and their team’s time. Time 
management stretches to almost every part of the job. Prioritizing the right 
work and delegating nonessential things is paramount to getting a product 
out the door. The interviews revealed that the top product leaders think of 
time as their most precious commodity. Tactics for efficient time manage- 
ment include reducing the frequency and duration of meetings, saying no 
to distractions, delegating wherever possible, and being fiercely protective 
of their time, all while making quality time for their team and customers. 
Time allocation will be very contextual and dependent on the personalities 
of the leader. We’re advocates for allocating time for uninterrupted, 
focused work, but we’re also aware of those rare examples where leaders 
are capable of achieving high outputs with shallower interactions. The 
book Deep Work: Rules for Focused Success in a Distracted World by Cal New- 
port (Hachette) explores these concepts in depth and is recommended for 
all product leaders. 


Is a visionary. Product leadership, by definition, requires a vision for 
where the product has to go. According to GV’s Ken Norton, “There are 
examples of great leaders who weren’t visionary but were great at making 
tactical decisions, which is perfect for taking a hill in a battlefield. That’s 
leadership. But product leadership requires a vision of where you need to 
be. What does this product need to be in five years? How are we going to 
get there? And how do J articulate that vision so that everyone else has it in 
their head, too? There’s the sense of a North Star that you’re aiming 
toward; that’s important to this type of leadership.” For great product lead- 
ers, this means “internalizing the vision, it means buying the vision, it 
means loving the vision,” adds author and consultant Rich Mironov. “And 
that means you end up being the visionary.” 


Shows equanimity/grace under fire. Being equanimous is tightly connec- 
ted to the “plays well with others” trait we discussed earlier. Structuring 
equanimity into daily and weekly activities and meetings is the job of the 
product leader. “We practice equanimity—the idea of taking all this emo- 
tional anxiety and trying to structure it, understand it, and channel it into 
productive output,” says Jeff Veen. Google spent two years exploring what 
makes a team effective, including 200+ interviews and measuring 250+ 
attributes of 180+ active teams. Its conclusion? That the individual mix of 
traits and skills in the team was the least likely predictor of success. Who is 
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on the team matters much less than how the team interacts, and the num- 
ber one dynamic that defined successful teams was a sense of psychologi- 
cal safety—a sense that the team would not embarrass, reject, or punish 
someone for speaking up. Being able to instill this sense of psychological 
safety and trust is a key part of the product leader’s job. 


While making a list of ideal skills is easier than finding the person that exhibits 
all of them, we maintain that a majority of these would be present in a good 
product leader. Our experience has taught us that even when some of these skills 
are absent or poorly developed in a leader, that leader is aware that these skills 
are important and worth developing. 


Hiring Product 
Leadership 
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The qualities to look for in a product manager or leader should be clearer by 
now, but that’s only half the battle. Knowing when to hire is the other half. Com- 
bining the search for quality leaders at the right time is no small task. The health- 
iest organizations treat this challenge like they do sales—as a pipeline problem. 
To ensure you have strong candidates to cover any growth or hiring demand, you 
need a talent pipeline. This pipeline will look different at each stage of your busi- 
ness, but there needs to be a funnel that takes in candidates and then either 
qualifies them or prepares for the next stage in the hiring and onboarding pro- 
cess. Staying true to the format of this book, we’ll look at what’s required to hire 
for each stage of the product business. We'll also talk about how you can craft 
your own leaders using programs like apprenticeships. 


If a startup hires a senior manager or leader too soon, it runs the risk of overcom- 
plicating the process and slowing down delivery, not to mention spending money 
when it may not have enough to invest. For high-growth companies, it’s hard to 
gauge how much impact the leader can have at scale. Founders, executives, and 
hiring managers also need to know if and when they should hire product leader- 
ship, as there are some scenarios where senior product leadership is not going to 
have a material impact on the business or product. There are also situations 
where an external consultant, agency, development partner, or design firm can 
get the work done. 


Hiring and Onboarding Product Leader Talent 


Senior executives or a hiring manager looking to hire a new product leader might 
be inclined to think of them as a glorified engineer or a strategic-minded user 
experience designer. They would be wrong. Engineering, design, and marketing 
are critical to the product creation process, but do not automatically translate to 
product leadership. Hard skills are not a proxy for soft skill management or lead- 
ership. Product leaders need the requisite skills to mentor, guide, coach, and 
manage people. They also need to have a broader vision than just business, engi- 
neering, design, or marketing alone. They need to see the big picture and be able 
to talk shop with all these disciplines. They need to be able to communicate up to 
senior leaders, while effectively managing their teams and partner relationships. 
That’s not all: they also need to understand the user’s needs and advocate for 
those needs throughout the product creation process. Hire for the challenge 
ahead, not for the experience behind. 
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When you hire good people, you make your job as a leader easier. Jason Fried of 
Basecamp talks about “hiring a manager of one’—the idea that a great hire 
should be able to manage themselves. We like this concept. It doesn’t mean the 
person you've hired doesn’t need support, guidance, and mentoring, but it does 
mean they won’t need to have their hand held every minute of the day. It also 
doesn’t mean the person you hire has to be a manager. Managing yourself is not 
the same as having the title of manager. 


Your goal as leader is to add people that make your job, and the jobs of the other 
team members, easier. The best way to do this is to hire people that are going to 
produce a multiple of what others can produce. Someone who is generating two 
or three times the value of the average person is also going to cost you less— 
maybe not less money, but less frustration and less time. If you suspect for a 
moment that a person is going to create more work for you, don’t hire them. 
Beyond the necessary onboarding and orientation, if a new hire is taking up all of 
your time, they may not be the right person for the job. 


Great hires can be identified with a few simple observations. Good product peo- 
ple understand that it’s a team sport and will have a deep interest in how that 
team operates. Their focus should be on the team, the end user, and the environ- 
ment the team works in—both physically and situationally. Ideally, they will ask a 
lot of questions. Encourage them to do so, even if they are nervous. It’s normal to 
be nervous in an interview, so your empathy and understanding will be appreci- 
ated by the interviewee. 


Great product people will also ask questions about the product, the market, and 
the business, but they should also show an interest in who they will be working 
with. Listen closely for these traits. Do they ask questions about the team? Do 
they inquire about what makes the team good/interesting/productive? Do they 
ask about your leadership style and how you manage others? Do they express 
empathy for others? Do they understand that producing great products can be 
difficult and frustrating, but still want to do the work? 


If they do all the talking and ask no questions, don’t hire them. If they don’t lis- 
ten and talk over you, don’t hire them. If they come unprepared to show you 
their creative artifacts (previous products, portfolio, code, prototypes, experience 
maps, etc.), don’t hire them. If they can’t articulate why they would be useful to 
the team, seriously consider why you need them. 
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This may sound uncompromising, but hiring the wrong person can create a 
long-term problem for you and the team. Have too many interviews than too few. 
Check references, ask for additional information, have team members meet the 
prospective hire. Do whatever it takes to get to know candidates and see if there 
will be cultural fit. 


As obvious as this sounds, leaders need to be able to lead. Leadership is almost 
always a learned skill. Very few people are born with all the hard and soft skills 
that make leaders what they are. For hiring managers and the executives who 
decide who will be on the team, this is the quintessential part of the job—not 
assuming that everyone will lead just because they are put into a leadership role. 
Find people with leadership skills and then train for leadership in the context of 
your organization. Never leave this to chance. 


Furthermore, great product leaders need to lead in good times and bad times. 
Nothing in business is ever guaranteed. Markets shift and technology disrupts 
entire sectors. Engineering skills alone won’t help a leader navigate a challenging 
situation, and even within the microenvironment of the organization itself, 
things will change. For high-growth companies, where the team is going to 
expand quickly, hiring for that leadership skill set is more important than ensur- 
ing the product manager has expert-level Photoshop skills. 


A product manager in line for a leadership position may face similar challenges. 
For example, a designer who has become a product manager might face the per- 
ception that they care exclusively about design. This perception can become a 
problem, and that person will need to demonstrate that they can handle the 
demands of leadership that lie outside their comfort zone. Product leaders need 
to learn all aspects of the product creation process. That means breaking out of 
the known area of expertise of past experiences and getting into the details of the 
other areas. It also means learning to delegate things that they were good at to 
people who may be better qualified. “For those looking to break into product 
management, look at your current role and experience,” says Vanessa Ferranto, 
Senior Product Manager at Zipcar. “Find what you have done that applies to the 
role of a product manager and leverage that experience as you look for your next 
opportunity. Go to events, network with people, and look at job boards for exam- 
ples of product manager descriptions.” 
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Not all product leaders are hired from outside the company. Often, they are pro- 
moted from within or end up with the job because they have closely related skill 
sets. If you’re hiring from inside, the considerations are very similar to hiring 
from the outside. Seek out the folks that care deeply for the product and the cus- 
tomer. In simple terms, this boils down to curiosity and empathy. “For people 
who actually fall into product management at their current company and are just 
trying to figure out what to do next, I think it’s about being curious, not just 
about your products, your business, and your customers, but curious about the 
discipline of product management itself,” says Ferranto. 


Being both the product manager and the best engineer on the team will become a 
problem. Technical skills are not the entire responsibility of the leader, and the 
product leader should never be the most highly skilled technician on the team, 
because they need to be elevated out of the day-to-day technical work. This might 
take time, but it must be a priority. Bottlenecks are called that because they are 
always at the top of the bottle. A good leader must know when to let go of the 
practical product-making work and hire people that can do their job better than 
they can. 


Even when product leaders are not directly involved in the hiring process (which 
is rare and ill advised), they will still need to leverage what they have to deliver 
value. Many product leaders inherit their teams. Promoted or product leaders 
hired from outside the company may have had no role in the hiring of those peo- 
ple. This is not an excuse to throw up your hands and exclaim that you’ve inher- 
ited a mess. Strong leadership means getting to know the team. Knowing their 
strengths, weaknesses, fears, and ambitions gives the leader the opportunity to 
develop rapport with the team. This rapport makes it easier to deal with the inevi- 
table challenges that come the team’s way. 


Product leadership isn’t just design or engineering or business or marketing. It 
is all of these things in a sandwich of stress and competing expectations. This sit- 
uation is obvious to anyone that’s ever been a product manager or leader, but it’s 
not obvious to everyone else. Sometimes it’s not even obvious to their team 
members, especially those who are focused on a single part of the process. The 
challenge seems to be that the product managers know what they do, but others 
don’t always know. It’s the responsibility of each product leader to advocate for 
themselves and bring awareness to the entire team. That means both talking 
about the role and demonstrating how it works. One solution might be to embed 
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technical people with product leaders so they can see how they work and what 
they’re up against. For the product leader, this demands some personal reflec- 
tion. Self-assessment and peer conversations will help identify the best and worst 
parts of your leadership skill set. “Mentorship is a great opportunity to bounce 
your thoughts off somebody with more experience,” suggests Ferranto. “My 
greatest piece of advice is to keep learning; educate yourself, understand what 
skills you have and where you need to improve.” Knowing your product leader- 
ship strengths and weaknesses will provide a clearer path to delegating and hir- 
ing. 


Onboarding new managers and leaders might be the most overlooked part of the 
hiring process. Many companies assume that the new hire either will have the 
skills, or, if not, will learn on the job. This is a mistake. Not even the most accom- 
plished leader walks into a new job without some kind of orientation, and we’re 
not talking about a tour of the office and kitchen. Onboarding should be a 
detailed checklist that covers all aspects of the new leader’s job. Fresh Tilled Soil 
took inspiration from surgeon Atul Gawande’s best-selling book The Checklist 
Manifesto (Metropolitan Books) to develop a bulletproof onboarding process. 
Gawande describes how even the most educated and highly trained professio- 
nals, like surgeons and airline pilots, rely on checklists. They don’t trust the falli- 
ble memories humans are burdened with. Gawande suggests that all professions 
benefit from checklists, and we support his insights. This idea gave us a frame- 
work to build an onboarding plan, but it didn’t happen overnight. The 44-step 
onboarding checklist" Fresh Tilled Soil uses today was developed over time and 
edited as they learned what was working and what was just getting in the way. 
Over about a year, the onboarding process has been further refined into two 
stages: an initial two weeks of mostly administrative tasks and meet and greets 
with the team, referred to as bootcamp, followed by a six-week onboarding where 
new employees spend time with their teams in formal and informal sessions. 
These sessions ensure they’ve covered every detail of the work and actively 
deepen bonds between the team members. 


TIMING FOR HIRING 


Hiring might not always be the solution. Sometimes it’s possible to train the 
existing team or adjust the workflow or process to get the results you seek. Hir- 





1 Ilan Mochari, “This Design Firm Has a 44-Step Onboarding Checklist”, Inc. 
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ing a new person creates new problems and new challenges. Can we afford this 
person? Will they fit in culturally? How long will it take for them to get up to 
speed and create real value? Will they bring their own style of work and disrupt 
the current flow? These questions need to be answered before new people are 
added, and in order to do that, you may need to analyze the current state of the 
organization. Understanding the existing pain points and problems of the team 
gives the decision maker the confidence to either make the hire or postpone until 
another time. Here are a few questions to kick-start that analysis: 


e Do we have someone who can clearly articulate the product vision and 
ensure it is executed correctly? 


e Are we missing growth or value opportunities because the current team is 
too focused on iterative adjustments or bug fixes and not on innovative 
improvements? 


e Is there product ownership? Someone with final responsibility for deliv- 
ery? 
e Are politics creeping into the process and derailing the work? 


© Is the team easily distracted by new ideas and feature requests? 


e Is there a clear path from discovery to delivery? 


We've heard, and witnessed, that adding another layer of management can slow 
down the workflow. If this is the case, then the fault usually lies with the man- 
ager. A good manager is always adding value. A great manager will be self- 
actualized enough to know that if they are unable to add value they should either 
step away, improve their skills, or bring in someone who can fill the gaps. If a 
manager is slowing things down, then they are not solving problems. Adding a 
good leader should improve and amplify the team, not slow it down. 


TIMING FOR FOUNDER-LED ORGANIZATIONS 


As we mentioned before, context is everything, so let’s discuss different organiza- 
tions and the pressures that lead to hiring a product leader. We’ll start with com- 
panies that are founder-managed. These are most often startups, but as we’ve 
seen with so many software companies in the past few decades, this can also 
mean high-growth and even enterprise-sized companies. 
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If the founder is also the most senior product leader, then at some point this per- 
son will change roles, relinquish their product-related duties, or possibly even 
exit the company entirely. All of these scenarios will result in a vacuum of prod- 
uct management or product leadership duties. This transition is often the hard- 
est part of growing a founder-led product company. Assuming they want to let 
go, a hands-on founder will need to have the maturity to relinquish their involve- 
ment in the day-to-day product work. This can be practically difficult, as the com- 
pany might be relying on their technical skills. It might also be politically difficult 
if that founder becomes less relevant as new product skills are required. It’s 
never easy for a founder of a product to realize they are no longer needed, or that 
the situation has outgrown their skill set. The art of managing a team is inher- 
ently difficult and complex. A founder might not have these skills and may 
require a new hire to lead this effort. How a founder adapts to the growing com- 
pany needs will impact the decision to hire a junior product manager, senior 
product leader, or a consultant. 


In the most common scenario, a founder might need a product manager to take 
over some of the practical work while they turn their attention to temporary pri- 
orities like fundraising, initial sales, hiring a team, or general operations. In this 
case, the founder still has oversight on the product vision and strategic elements 
of the work. Hiring a competent product leader that reports directly to the 
founder might be all they need to keep the momentum going. 


In the second scenario, the founder finds themselves being pulled permanently 
away from product management. This might be because they lack the skills to 
deliver an increasingly complex product, because of a high demand for growth, 
or due to the discovery that they are more valuable in other executive functions. 
To fill this skills gap, a senior product leader will need to be hired. 


In the case of the founder needing someone to manage the ever-expanding team, 
an experienced product leader will be required. This often happens when an 
early-stage team suddenly gets market traction or raises money. Whatever the sit- 
uation, a team will grow dramatically in response to market pressures. If this 
happens, then a founder may need to hire a seasoned team leader who can assist 
with responsibilities like hiring team members, implementing processes, and 
upgrading tools. 
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“I give a lot of credit to Travis, who gave me the autonomy I needed to do the 
things I wanted to do,” says Mina Radhakrishnan, who took over the product 
leadership from Uber founder Travis Kalanick. “Of course I expected him to be 
involved, but he had this mindset that the reason he was hiring this person to do 
this job was because he couldn’t focus on it 100%. He expected me to be focused 
on it 100%. This is a really important part of the company—he is involved, but 
doesn’t have to be micromanaging things.” 


Recognizing that, as a founder and CEO, you can add more value to the business 
by focusing your time and energy elsewhere—from building the team to raising 
investments—is a good sign that it’s time to hand over the reins. 


It’s also important to recognize that this transition won't be easy. As a founder, 
you're handing the reins of your product strategy to someone else, and there will 
be tension. Paul Adams, VP of Product at Intercom, elaborates: “We had a lot of 
tension in the beginning. I think in any healthy relationship you have difficult 
conversations, disagreements. But I think we had a strong relationship. The 
founders and I have always been very direct and honest with each other, and I 
think that served us well getting through some of those tricky discussions early 


” 


on. 


TIMING FOR EMERGING OR HIGH-GROWTH COMPANY HIRING 


For companies that have expanded beyond the startup phase and have a product 
team that has been working together for a few years, the challenges of hiring 
aren’t confined to external hires. As teams grow, transitioning existing team 
members and recognizing internal talent becomes just as important. For many 
high-growth companies, the biggest business challenge is managing scaling 
without imploding. If the team already has a few product managers and an estab- 
lished team of designers and engineers, they will need to shift from trying to ship 
product to managing for scale. 


The choice is either to promote an existing team member to a senior product 
leadership role or to find someone who has the experience to scale and lead the 
team. If the team is showing signs of maturity and adaptability, the talent 
required is likely to be found within. If the team gets increasingly chaotic as they 
grow, it will be necessary to hire someone to restore control and develop a culture 
that’s ready for fast growth. The timing of the promotion or hire will be obvious, 
but there’s always a catch, and that might be the product complexity. 
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On the surface, the timing for a strong senior product leader might appear 
straightforward, but it all depends on the complexity of your product and market. 
If your product is extremely complex, then your product team will need someone 
that can deal with that, while also bringing strong people skills to the group. 
Technically complicated products require product leaders who either have deep 
domain knowledge or the capacity to get up to speed quickly. These people can 
be difficult to find, and it may be necessary to hire for the soft skills and train for 
the technical skills. 


Simpler products demand less from product leaders from a technical point of 
view, with the benefit that the emphasis can shift from solving complicated tech- 
nical issues to team development to sales and marketing. In these cases it’s pos- 
sible to pass some of the product leadership responsibilities to other key team 
members, like head of UX, design, or engineering. 


TIMING FOR HIRING AT ENTERPRISES 


Many of the guidelines provided for founder-lead and high-growth companies 
will apply here, the difference being that an enterprise will require specific lead- 
ership jobs, not just general product leadership. As we’ll demonstrate in the fol- 
lowing section, it may be easier to hire for a larger organization because there are 
narrower problems to solve and it’s possible to target more specific skill sets. 
Enterprises also tend to have longer lead times between projects and ship dates, 
which means more time to recruit and make the right hires. Whether time is an 
issue or not, these new hires should always be in response to a pain that has 
become unbearable. As investor Jonathan Beare says about new hires, “Better to 
grow out of your shoes than into them.” 


By now the enterprise product organization will have several product managers 
and senior leaders. New managers and leaders should be hired only when a spe- 
cific problem needs to be solved, not because you have an open position on the 
org chart or in the budget. For example, if a team has encountered ongoing and 
challenging UX problems but the current members are weak at UX, then hiring 
new talent might be unavoidable. Each new hire should improve the team, which 
means balancing the need to solve specific problems while trying not to disrupt 
the flow of the existing team. We highly recommend making a hire only when 
both the specific problem can be solved and the overall value of the team will be 
raised. 
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APPRENTICES: CREATING YOUR OWN PRODUCT LEADERS 


We've discussed hiring product leaders from both inside and outside the organi- 
zation. What we haven’t covered yet is the optional step that comes before hiring: 
building your own talent. For many product organizations, nurturing new prod- 
uct leaders from other disciplines is part of their talent strategy. As we said at the 
start of this chapter, the most prepared and successful product organizations 
think about talent the way they think about sales—as a pipeline, a never-ending 
cycle of adding, qualifying, and stewarding potential. A good way to feed that 
pipeline with high-quality candidates is to create an apprentice program, which 
can be very successful but is frequently unvalued. 


A well-known apprentice program in the product manager space is Google’s 
Associate Product Manager (APM) program, the company’s product manager 
training program for college graduates. Originally conceived and created by Mar- 
issa Mayer, the program was Google’s way of developing product leaders. The 
typical APM is a recent graduate who majored in either computer science or 
math, and as with most apprenticeships, the aim is to develop these candidates 
into full-time positions through a combination of training and hands-on involve- 
ment with real projects. As Google describes it: 


As part of the Product Management team, you bridge technical and busi- 
ness worlds as you design technologies with creative and prolific engi- 
neers and then zoom out to lead matrix teams such as Sales, Marketing 
and Finance, to name a few. You have a bias for action and can break 
down complex problems into steps that drive product development. As an 
Associate Product Manager, you can be part of shaping Google's next 
game-changer. 


Yahoo, Yelp, Facebook, and others now also have their own product manager 
apprenticeships or training programs. In all cases the prospective program sets 
up managers for working with operational teams across the organization. This 
combination of coursework and responsibility helps candidates develop the hard 
and soft skills needed in the future high-pressure role of product management. 
Giving the APMs responsibility and ownership above their experience level or 
skill set provides them with a practical education that would be difficult for them 
to find anywhere else. “We spent a lot of time working with the people who ran 
the Facebook APM program to get a sense of how they think about things,” says 
Mina Radhakrishnan, previously Product Manager at Google. “We did research 
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on different rotational management programs and talked to the people who cre- 
ated them and who were able to find the right balance of having a good structure, 
where people have the chance to learn and also to fail. I think that’s the best way 
to learn—have people stretch themselves, see what they’re doing wrong, and 
make sure to course-correct along the way if necessary.” 


How apprentice programs can support product leadership 


Apprentice programs are undoubtedly valuable, but they can be time-consuming, 
and they require supervision and management. Small companies or startups 
may not see the long-term value of these programs. Larger companies might 
struggle to see the relevance of an internal program when they can solve talent 
problems through traditional hiring methods and talent acquisitions. The fact 
remains, however, that all organizations, big or small, benefit from having talent 
that feels cared for and valued. Apprentice programs are relatively short time 
commitments that reinforce the idea of investing in your talent while simultane- 
ously reducing churn, cost of hiring (recruiters and advertising), and time wasted 
interviewing poorly matched candidates. 


When implemented correctly, the apprentice programs make the product lead- 
er’s work easier and more effective. For those wondering how to do this correctly, 
we'll provide links to how you can create your own program at the end of this 
chapter. Having a pipeline of talent reduces the burden on the leader to ensure 
that there will always be great people on the team. Furthermore, a product team 
that has apprentices working side by side with them will benefit too. The team 
will develop rapport and understanding with their future full-time team mem- 
bers, while benefiting from the added bandwidth and support that comes from 
additional talent. 


The best product managers are not just thinking about today’s challenges and tal- 
ent needs—they are thinking months and sometimes years ahead. We believe 
that nurturing a future collection of product talent is not just a nice-to-have, but a 
requirement of success for product leaders. 


How to create an apprenticeship program 


So how do you create an apprentice program that attracts and develops the best 
talent? Part of the media mythology of attracting creative problem solvers is that 
you have to employ tattooed, bicycle-riding hipsters and provide them with fair 
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trade coffee, ping-pong tables, and beanbags to get results. Not only is that a 
paper-thin idea, but unfortunately it’s also what most companies end up doing. 
In the real world, product leadership or management is a complex role driven by 
hard constraints and complicated projects. Just being a creative problem solver 
isn’t enough. A creative mindset may be the price of entry, but it’s not going to 
carry you through the minefield of managing a difficult product. Designing a 
team that can deliver on these high-stakes products while still making a profit 
requires a different model. 


Being consistently creative and productive is not about moments of lightning- 
bolt inspiration but rather about methodical, iterative problem solving, supported 
by discipline and training. That training and discipline doesn’t happen acciden- 
tally for forward-thinking leaders. That’s where an apprenticeship program 
comes into play. 


The critical element to success with these programs is having thoughtful team 
players that are disciplined problem solvers, because when your plans fail, you 
need a team of people who can think fast on their feet. As Mike Tyson said, 
“Everyone’s got a plan until they get punched in the mouth.” Surprises are the 
kind of thing that product managers and leaders deal with every day. Apprentice 
programs should design challenges that reinforce this to show candidates how to 
respond when things get tough. 


Clearly this agility in problem solving is not restricted to product teams. It’s also 
true of high-performing sports teams and companies that demonstrate long-term 
success. The business version of this is superbly described by Jim Collins in his 
groundbreaking book Good to Great (HarperCollins).* The common thread in all 
high-performance situations is that the outcomes and processes are built around 
high-functioning teams, not the other way around. The right process doesn’t dic- 
tate success. The right teams do. The best apprenticeship programs teach this by 
throwing their apprentices into the deep end of real-world projects. Instead of 
relying on textbook or course learning, they immerse their teams into actual 
projects with actual stakes. 


At the highest level, apprentice programs are a series of filters to recruit and 
select the best possible candidates for a team. For this reason alone, making the 





2 Jim Collins, Good to Great, (HarperCollins). 
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entry requirements challenging is an important part of the process. Try not to 
use recruiters or job sites. Instead, use an incredibly tough entry program to chal- 
lenge the best of the best into proving how good they are. Hackathons, competi- 
tions, and timeboxed challenges are very effective ways to set a high bar for 
recruitment into these programs. 


Unlike interns, apprentices are generally full-time employees of the company 
and should be compensated accordingly—not only because they work on real 
products, but also because it allows the company to set a higher standard of 
recruitment. Unpaid programs feel temporary, like internships. That’s the oppo- 
site message of what apprenticeships want to signal. Of course, once a candidate 
has completed the apprenticeship program, there is still no guarantee they will 
be hired as a full-time team member. Paying an apprentice and paying someone 
to manage them is an investment. At face value this might seem like a lot of 
effort for the return. However, the outcome and the economics make sense. Pay- 
ing a recruiter or making the wrong hire is far more expensive and disruptive. 
Making it hard to get into the program and making the program challenging is a 
powerful filter. If someone is going to be groomed for a senior product manage- 
ment role in the company, then this investment is worth the money and the 
time. 


It’s possible that programs like this will be perceived as extra work for the prod- 
uct team, who might feel frustrated that they have to take time out to help the 
candidates. “There was definitely pushback,” says Radhakrishnan. “Are we doing 
this too soon? Do we have the right level of leadership and hierarchy in the com- 
pany, before we hire these people? Is it the right time? However, once people 
came on board, they were seen as excited and eager and ready to work. It was a 
good boost of energy to have eager, young people ready to dive in and learn and 
work on things.” Soon teams will start to see how these fresh faces can add value 
and take on projects well above their level. 


For those interested in building apprentice programs, we’ve written a detailed 
and practical playbook for how to create and run an apprenticeship program. The 
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open source curriculum can be found on our website? and is also available on 
Medium.‘ 


A CASE FOR LONG-TERM COMMITMENT TO PEOPLE AND TEAMS 


There is a common suggestion that high staff turnover injects the product com- 
pany with new ideas. The downside of this type of broad advice is that it pays no 
attention to how people collaborate. As in any collaborative relationship or team 
setting, keeping staff for the longest period possible is optimal for problem- 
solving work like user experience design. Deep collaboration between team 
members is essential for high-stakes projects. Having a team that’s worked 
together over multiple projects creates the right chemistry, which stutters each 
time you add new people to the mix. 


In reality, fast-growing companies need to add new people, and a large company 
is likely to have a natural churn of people as they move and adjust to any new 
circumstances. Keeping a core team together through the natural ebb and flow of 
the members isn’t always easy, but any pain can be ameliorated through an 
apprenticeship program that allows for a smooth entry point, and provides the 
opportunity for the broader teams to get to know one another before they work 
together. 


The expectation for product teams is often that they are experts who can solve 
product problems quickly. In order to live up to expectations, the teams require 
the internal chemistry of a well-oiled machine. Ongoing training, good chemis- 
try, and long-term vision—qualities that would be attractive to any leader—pro- 
vide the ingredients for a team capable of performing at a level that is simply 
unattainable by less prepared or bureaucratic companies, hamstrung by poor hir- 
ing policies. 


Becoming a Product Leader 


Product leadership is complicated for all the reasons we’ve discussed so far, 
which may not be surprising. What is surprising is why it’s complicated. On the 
surface, the complexity of shipping software products can be associated with 


3 Check out the Product Leadership book website. 


4 Steve Hickey, “The Future of Product Design Apprenticeships is Open Source and Practical Application”, 
Medium. 
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technology, process, and market-fit factors. In reality, those things are less fore- 
boding than managing the diverse sets of human skills needed to be successful. 
In almost all product delivery, it’s the people problems that need to be solved. If 
you were an engineer or a designer before becoming a product leader, then you 
quickly went from coding or page layouts to dealing with people and their prob- 
lems. If your background has been technical, then this transition can be unnerv- 
ing or confusing. 


In discussions about product leadership in the context of product companies, 
there is universal agreement that this is a job that has less authority than it 
appears to have. It also requires individuals and teams to achieve their goals 
through the application of soft skills, such as strong communication, good pre- 
sentation abilities, effective lobbying (how people convince and persuade others), 
and naturally, being a good negotiator. Related to this is the disconnect between 
position and authority. Many product managers assume that because they bear 
the title they automatically have authority, which, as many are now realizing, isn’t 
the case. 


For experienced product leaders, this disconnect is clear. Knowing that authority 
isn’t directly associated with the role, and understanding that incongruence, has 
given mature leaders the insight to change their behavior and how they develop 
their leadership skills. Instead of relying on an authority that doesn’t exist, they 
work harder to develop the tools they need to do a better job. They focus on 
becoming important influencers within their organizations and they hire team 
members—engineers, designers, or product managers—who share these skills. 
This is the big story in product leadership, and it’s essential to encourage more 
conversations around this topic. 


Moving from being an individual contributor to a product leader means recogniz- 
ing that you need to stop thinking just about the product and bring to bear all 
your experience, empathy, communication, and problem-solving skills on the 
company, the team, and ultimately the people who will actually build the product. 
Setting them up for success will lead to a successful product. It’s our strong opin- 
ion that for good leaders, every day starts with the question, “What can I do to 
make the people on my team successful?” 


Here’s a checklist for what it means to become a great product leader: 
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e Do what leaders do. If you’re new to a leadership role, then your first job is 
to understand what leaders do. Use books like this one to study leadership. 
More often than not, leadership is a learned skill. Leading doesn’t mean 
shouting commands and ordering people around, it means aligning your 
team behind a common goal. To do this, you'll need to identify the team’s 
strengths and weaknesses and leverage them on the best path toward the 
goal. Leaders don’t always look like you expect them to. There are plenty of 
leadership styles—some of which we discuss in this book—so find the one 
that plays to your strengths. Some leaders lead by example; others, with 
charismatic personalities or by putting their team’s needs first. Whatever 
you choose, make sure it resonates with who you are. Trying to be some- 
thing you’re not is exhausting and unsustainable. Great leaders are always 
true to who they are. 


e Articulate a clear vision and the path to get there. Vision is a common 
theme in this book, and for good reason. Without a clearly articulated 
future to work toward, your team will become distracted and unfocused. It 
is painful to see a good team slowly drift off-course until it’s too late to 
course-correct. As the leader, you should know better than anyone else 
what the company and product vision is. You achieve this by sitting at the 
table with other senior leaders and ensuring that there is clarity around the 
vision. 


e Protect your team. Similar to the above, leaders need to keep their team 
focused. The best way to do this is to articulate the vision clearly, and then 
protect them from distractions. Interruptions can come from many sour- 
ces: executive decisions, customer feature requests, and bugs that knock a 
team off-course. The role of a product manager is to interpret whether 
these requests are really important or just distractions. Part of this filtering 
sometimes means saying no to requests, which can be hard to do at first, 
but it gets easier. Teach yourself to filter, prioritize, and delegate, and teach 
your team to do the same. 


+ Create a process that delivers the best results. Leaders ask great questions, 
having learned that knowing all the answers is neither necessary nor possi- 
ble. Instead, they spend time working on the best questions to get the best 
solutions from their teams and partners. Part of this work is developing a 
process that ensures you always give your team the best chance at success. 
In his book The Checklist Manifesto (Metropolitan Books), Atul Gawande 
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reminds us that even surgeons and pilots need a bulletproof process to get 
their jobs done effectively, and even the smartest and most well-trained 
people miss a crucial step or forget a task. Keep in mind there is no perfect 
process, and being Agile or Lean is not enough. Discover what makes your 
team the best they can be, and amplify those things with process and rigor. 


Optimize your tools, but don’t get bogged down. Tools are supposed to 
make us better at what we do, but they aren’t what we do. It’s easy to get 
dragged into the debate about which tools to use and how to implement 
them, and in all cases the best tools make our jobs easier and support our 
efforts. Generally tools are less important than their marketing purports 
them to be. The best tools also tend to be about improving communica- 
tion; after all, product management and delivery is almost all about com- 
munication between people in the process. Understanding your team’s 
personalities, communication dynamics, and culture is the first step in 
determining which tools to use. Mapping these human dynamics to the 
overall product vision and the chosen process will expose any potential bot- 
tlenecks. We recommend making a three-column page, with a list of the 
tools you use and the tools you think you might want to use in the far-left 
column. Then, in the middle column, write down the problems the tools 
solve for your team and organization. Finally, in the far-right column, 
write down what would happen if you didn’t have the tool. This process is 
a form of spring cleaning. It’s a way to start the conversation about what is 
essential and what is just taking up space. Having all these considerations 
in place makes it easier to select the optimum tools for your specific cir- 
cumstances. 


Be serious about customers. The customer might not always be right, but 
they are the best source of information and feedback on your product. 
Smart product leaders know this and make the time to get in front of their 
customers on a regular basis. Research, data gathering, analytics, and 
interviews are all important sources of information. Qualitative and quan- 
titative data needs to be part of the product leader’s day. We’ve listened to 
some product people who say they are too busy to talk to the customer, or 
that the customer doesn’t know what they really want. But making excuses 
for not testing ideas might be detrimental to a product’s success. 


Be there when you're needed, but otherwise stay out of the way. A product 
leader is required to remain intimately involved with their team’s daily 
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work, while simultaneously returning authority to the team. They should 
be present at meetings and available for questions, yet also allow their 
team to make their own decisions, solve problems, and trust their own 
choices. This isn’t something that should be left to chance. School doesn’t 
always teach people to be thoughtful decision makers, so leaders may need 
to train team members on how to do this. 


There is a lot of concern among product leaders that they’re doing it wrong, that 
they’ve picked the wrong process or are using the wrong tools. The chatter on 
product channels is cluttered with questions about what tools and tech to use. 
For many leaders, these are the wrong things to be focusing on, particularly since 
tools and tech change so quickly. The conversation should always be about peo- 
ple. However, managing and leading people is hard, which is why it’s easier to 
talk about tools and technology. 


Tanya Cordrey, former Chief Digital Officer at the Guardian, agrees: “It’s not for 
all product managers. I think a lot of organizations, when you’re building prod- 
uct teams, you’ve got people who are natural leaders and you’ve got some people 
who are natural individual contributors. For the most part, good product manag- 
ers tend to be quite good leaders because they’re good at managing people—but 
they might not necessarily like doing it. Make sure it’s something you’re good at 
and that you like.” 


Some leaders won't admit that they don’t know what they’re doing when it comes 
to leading people, and through their resultant defensive behavior, can unknow- 
ingly derail projects or hurt their colleagues, without even meaning to. Overcom- 
ing this isn’t easy, but it can be done. It’s the goal of this book to highlight these 
issues and provide some solutions. 


PART | II 


The Right Leader for 
the Right Time 


This part of the book is dedicated to helping product leaders figure out the best 
approach for each stage in an organization’s evolution. Our own experiences, 
combined with the experiences of hundreds of successful product leaders, will 
give you insights into how stage-specific problems can be solved. As much as 
we'd like there to be, there is not a universal solution to the question, “How 
should a product leader lead?” There is no single winning strategy or leadership 
style, but there are themes and patterns that run through successful teams and 
their leaders. 


We encourage you to digest these anecdotes, stories, and hard-won nuggets of 
knowledge, but with an eye toward developing your own personal style. Don’t fol- 
low blindly in the paths of others. Timing and context are paramount. What 
works for one company might not work for yours. Consider the context and envi- 
ronment of your own situation before putting these ideas into action. 


To make it a little easier to navigate Part II, we’ve separated the three chapters 
into the stages of a company’s evolution: startup, emerging, and enterprise. Feel 
free to skip to the category that is most relevant for your current circumstances, 
and return to the others when your situation changes. 


The Startup 
Organization 
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Startup Product Leaders 


If successful product leaders are a rare breed in the product universe, then suc- 
cessful startup product leaders might be the most exotic of the species. The 
tough challenges of the startup environment are often underestimated. Product 
leaders are expected to be both skilled practitioners in their market domain and 
have the ability to build and lead a team from zero to whatever milestones have 
been set. Most people prefer either building something from scratch or joining 
an established team. There are the extremely rare people who can do both. The 
smartest leaders acknowledge what they can do well and invest in that area. It 
might seem sexy to be in both camps, but trying to be all things to all people 
never produces impactful results. 


Although we’ve divided this part of the book into the three broad stages of a com- 
pany’s growth, we should also point out that there are definitely layers of growth 
that a company may experience within each of these stages. All businesses have 
some snowflake qualities; that is, they are all unique in their own way. Startups 
go through such rapid changes that our definition of the startup organization 
might not adequately represent every iteration of such sudden expansion. 


In the earliest stages of a startup, things are chaotic. Strategic plans tend to be 
ignored, if they exist at all, in the pursuit of tactical wins. John Maeda, previously 
of Kleiner Perkins Caufield & Byers, says, “In a big company, it’s about building 
a better culture that cares about the product. In startups, that’s easy—there’s no 
legacy holding you back from starting with a great UX.” These early-stage teams 
are made up of a handful of entrepreneurial types with a high tolerance for ambi- 
guity. They spend their time testing new ideas and clamoring for customer feed- 
back, and if they don’t have customers yet, they might be shipping first and 
asking questions later—often, as the adage goes, asking forgiveness, not permis- 
sion. Speed is everything at this stage because the runway is short. Funding 
might last only months, or a year at most, so there’s no time for overthinking. 


Assuming some success, this early chaos starts to be replaced by the need to hire 
generalists to get the piles of work done. Product people who like to wear a lot of 
hats find this stage the most appealing. There’s still no formal structure, so the 
emphasis is on removing obstacles and making decisions. As customers accrue 
so does the data, giving the product teams the indicators and evidence they need 
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to focus their attention. Hiring is challenging at this stage because the desire for 
just getting work done often wins over thoughtful recruitment and onboarding. 


By the time startups hit maturity, they have some rigor around their process, 
metrics they can accurately measure, and some alignment between product, 
sales, and marketing teams. The product team is now turning its attention to 
being more detail-oriented. Precise improvements that lead to significant 
improvements in acquisition costs and lifetime value become the order of the 
day. Team hires will lean heavily toward industry veterans with experience man- 
aging those precision changes. Managers and leaders become more formal in 
their approach. 


Through all these strata the product leader is evolving as quickly as possible or 
hiring others to fill in their knowledge gaps. This early stage is a race against 
time and ignorance. Next we'll cover some of the challenges you might expect in 
the startup phase and some solutions that emerged in our interviews. 


THE BIGGEST CHALLENGES 


When surveyed, product leaders consistently point to the future, and the lack of 
clarity it brings, as their biggest challenge. More specifically, they want to be able 
to plan ahead with confidence. They want to know that their roadmap will deliver 
the value they have proposed. In a startup, with the lack of product/market fit 
feedback, it can be extremely hard to know how to plan for the future. De-risking 
is a huge part of the product leader’s job. The right blend of experimentation and 
understanding the customer is necessary before products go into a marketplace, 
but sometimes not all that information is available. In many cases there’s not 
enough data or knowledge to make conclusive decisions. This is what Jim Sem- 
ick of ProductPlan calls the “fuzzy front end” of the product creation process. 


“The main part of the process is actually engaging with potential prospects of the 
product, and part of that is to do some decent market segmentation to really try 
to focus in on the segment that you'll be targeting. So many new products, espe- 
cially startups, will rave that their product is for everyone. That’s a very risky 
prospect,” says Semick. He and other successful product leaders aren’t willing to 
wager that they can be everything to everybody. Rather, they believe that you need 
to narrow the market substantially in order to target your prospects accurately. 
Once you’ve done this, you’ll be able to talk with them. You can’t talk to every- 
one, so brutally focusing on a small segment gives you a target for your limited 
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time and attention. Talking to this core user group provides the product/market- 
fit feedback you need to make confident decisions about what will work in the 
future. As product leaders we realize how stressful it is to operate in uncertainty. 
Successful leaders don’t resist this reality, but instead embrace it and become the 
masters of the “fuzzy front end.” 


Product leaders can’t ignore the chaos, so they learn to hone their skills to be 
comfortable with these environments. This means making a conscious decision 
to acknowledge that chaos will always be there in some form. Recognizing that 
chaos and ambiguity exist fosters a healthy mindset, which in turn reduces the 
associated anxiety. Leaders must discuss these environmental factors openly with 
the team. In their practice at Fresh Tilled Soil, the team talks frequently about the 
things they can control and the things they can’t. They ascribe metrics to the 
things they can control so they can determine if they’re actually making a differ- 
ence. For those things they cannot control, they list them and discuss ways to 
make them less harmful on both the process and their state of mind. The public 
recognition of these factors helps the leader and the team prepare for what’s 
coming and avoid being blindsided by inevitable surprises. 


This change in mindset allows product leaders to gain enough confidence to rise 
above the fray. They reframe their situation by focusing on what they can control 
and on the bigger picture, which shows the team where they should be keeping 
their attention. “The biggest challenge in startup product leadership is probably 
managing the tradeoff between setting a vision and working on the actual nitty- 
gritty. I think early on the nitty-gritty details of things matter a lot more, and 
you're going to have the CEO in the room talking about exactly how does this fea- 
ture work; you’re going to have the product leader sitting in the room talking 
about exactly how does this feature work. You're continuously going back and 
forth between vision and detail,” adds Ellen Chisa, VP of Product at Lola. 


This approach gets everyone in alignment and signals that they are on the right 
path. Uncertainty is part of the equation for success. It is also part of the equation 
for failure if you let it become your focus. Whatever the leader puts their team’s 
attention on will get the energy of the team. Focus on the vision, and you'll get 
there. Focus on the chaos, and you'll continue to reinforce it. 
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Solving the right problem 


Without doubt the biggest challenge for startup businesses is whether or not they 
are solving the right problem. Will their solution be something people are willing 
to pay for, and is there long-term value in this solution? Unfortunately, these 
questions require answers that are not always easy to provide to an early-stage 
company. That’s the bad news. The good news is that there are several things a 
product leader can do to avoid driving the business off a cliff. 


It’s been our experience that too many product managers and leaders don’t 
spend enough time understanding the problem before they start trying to solve 
it. They skip over the discovery work because they are too eager to get started on 
the solutions. We’ve all been in those early-stage discovery meetings when the 
team is already suggesting UX, UI, and engineering solutions before the prob- 
lem has even been defined. Having an awareness of this tendency can help to 
refocus thinking on the problem. 


Mike Brown, Product Manager at PatientsLikeMe, has a cautionary tale about 
how startups can focus too much on the shiny solution and ignore the glaring 
problem. Brown and his team were trying to solve the apparent problem of peo- 
ple not spending enough time outdoors: “One of the main takeaways from run- 
ning a web community of businesses like GearCommons was that we actually 
had two big problems that we could solve in the outdoor industry. The first rea- 
son people don’t get outside more is that they say they don’t have enough time. 
We felt like that problem was an ephemeral thing—helping people find more 
time to go outside is not a very straightforward problem to solve. The number 
two problem was that people lacked access to the right equipment. For example, 
if you don’t own a kayak, you don’t typically go kayaking. The outdoor industry 
requires you to have a lot of equipment that’s highly specialized and very expen- 
sive, and this is a barrier for involvement. The light bulb moment for us was that 
the number two problem—access—is one that we could solve using a sharing 
occurrence model, a Airbnb- or RelayRides-like model. So we really, really 
focused on driving access to equipment through the roof. We basically amassed 
over a million dollars in outdoor equipment here in Boston and then a number 
of cities throughout the country as well. With that being our goal, we succeeded 
in meeting the access requirement that we had set for ourselves. But in doing so, 
we had unintentionally caused a problem, which we only became aware of as the 
business kind of came to a close. Hindsight is 20/20. We found that by focusing 
on the number two problem, access, we had actually exacerbated the number one 
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problem, which was time. By amassing the equipment in one place, we increased 
the amount of time that it took to acquire a piece of equipment. We then found 
that people were actually willing to pay more money to spend less time acquiring 
equipment, but because we were so focused on increasing access, we didn’t focus 
at all on time. By creating this sharing economy marketplace, we actually exacer- 
bated the number one problem and we think that’s one of the big reasons that 
our platform never took off. So, the lesson is to always follow the number one 
problem, not the number two problem.” 


Balancing internal and external drivers 


Getting quality feedback from users can be both exciting and overwhelming. Bal- 
ancing this with internal drivers and ideas is difficult. Not all ideas for improve- 
ment need to come from the users. It’s perfectly normal and expected that the 
product team will have ideas of their own that they will want to implement. So 
how do you pull this together and determine what your product roadmap is, and 
what does that problem-solving process look like? How do you process all of that 
input to determine what goes on your roadmap or priority list? 


Jacquelle Amankonah, YouTube’s Global Program Manager, offers this advice: 
“We cannot do anything or make any decisions without the protection of our cre- 
ators and our viewers. I’m on the creator team. If I default to creator, that’s why. 
We use that as not only a data point, but as a starting point for us to determine 
whether we can balance this priority with our business priorities as well. Maybe 
there are things that we find are hard for creators or viewers to articulate, but we 
realize that if we act on this certain technology we can solve this very efficiently 
for them. We aim to validate that. We may ask, ‘If you could have a magic button 
that when you press, you end up with this completely automated thing, what 
would you want that to be?” 


Amankonah knows that posing broad questions to her team and to the user base 
won't help identify the right problems. “We definitely don’t just ask, ‘What do we 
feel like doing, guys?” she says. “Instead, we start with a prioritized list, a road- 
map. We have to make sure that everything we want to do, all of these great 
ideas, are cadenced in the right way.” Amankonah does this by creating a list of 
the things they want to design and develop. The team then discusses what the 
ideal timing would be as those things relate to each other. In other words, will 
the launch of one thing interfere or add value to another thing? Sometimes fea- 
tures need to launch at the same time to ensure they are adding appropriate 
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value, and sometimes they need to be separated to maintain their integrity. 
Releasing everything in one batch makes no sense for YouTube because users 
expect incremental improvements, not sudden and wide-reaching UX changes. 
“Those are the types of things that we aim to balance so that we have a very clear 
and cohesive story to the end user,” Amankonah continues. “Even if they’re built 
on different teams, we all have to work together to make sure we are making one 
choice as YouTube.” 


In developing a roadmap, all of those internal and external nuances have to come 
into play. What do we have time to do? What can we make time for? How many 
resources does the team have? What are our users’ most pressing needs? How 
can we make this happen in a technically interesting and innovative way? Once 
those questions have been answered, the team can start determining the best 
path forward. “Then we cross-check them against critical user journeys,” says 
Amankonah. “We have to make sure that creators want to achieve this very core 
flow. They want to make sure they can easily and simply upload a video, check 
how many views they got, or review comments received on a video uploaded last 
week. From end to end, if we’re able to deliver that smoothly within our product, 
then we’re good. Then we move to the next user journey to make sure it’s just as 
smooth. First, we have to get the foundation right, then we can build on nice-to- 
haves.” 


“Focus on the why,” Mina Radhakrishnan stresses. “There’s no point in building 
a feature if you don’t know why you're building it. You will always have a thou- 
sand ideas for what to build, but where does that lead to? What is the purpose of 
what we’re trying to do? How does this tie to our company goals?” 


Our interviews revealed so many good suggestions that we’ve created this cheat 
sheet for what product leaders should be thinking about as they balance the 
needs of the customer and organization: 


e Understand why you're solving this problem for the customer. 


Understand why the solution the company offers to the customer actually 
does what it’s supposed to do. 


Understand the problem you're solving for both the customer and the 
company, and how they connect. 


e Focus on the #1 problem, not on the #2 or #3. 
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e Build time with customers or users into your weekly product cycles. 


e Understanding the users’ most pressing needs by talking to them and 
observing them. 


e Develop a roadmap that outlines the core themes and priorities. 
e Determine how much time your team will have to implement the work. 
e Figure out if the team needs help from outside (freelancers, agencies, etc.). 


e Discuss the technical details of how to make the work interesting and 
innovative. 


The time that it takes for each team to gather this information and map it out will 
differ. Experienced product leaders will use a lens to direct the decision making 
and avoid scope creep or bottlenecking. That lens is almost always the company’s 
key set of goals. YouTube’s Amankonah says, “The way we do it is that we have 
OKRs that we use across Google. Most teams use OKRs quite heavily. We have 
annual planning, which is the end of the year. We just completed 2017 team 
planning, which includes taking a step back in our business to understand what 
went well, and where are we still missing key opportunities? What is the industry 
looking like? Where do we think it’s going? What big bets do we want to make in 
the next year? Our leadership teams get together, and using input from across 
the entire team, we try to land the key things that we want to ensure we hit in the 
next year. Those can be anything, from small changes or confirmation that we 
should continue something, to complete revamps of the company.” 


Using a lens like OKRs, the product vision, or other key metrics will help the 
team decide which things on the draft roadmap are worth executing. 


Getting to know your customer 


Throughout this book you'll see mentions of Directed Discovery, design sprints, 
and other discovery and research methods. These methods are extremely valua- 
ble, and successful product leaders reference them over and over again. 
Research, gather data, and prototype until you understand the problem and can 
articulate a solution clearly and without doubt. In a time when testing is 
extremely affordable and prototyping tools are practically free, there are no excu- 
ses for incorrectly defining the problem statement and associated solution. The 
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2016 InVision Product Design Report" suggests 87% of designers prototype dur- 
ing the design process. This is an encouraging number, but product leaders need 
to ensure that all members of their teams are doing this type of research and user 
testing as it relates to this prototyping. At Pluralsight, Fresh Tilled Soil, and Mind 
the Product, that number is 100%. No problem goes untested, because there’s no 
excuse not to test. 


It benefits you, the product, and the company to spend more time upfront vali- 
dating with other users and getting feedback before you build something. “The 
real cost of a feature is not what it cost in design, engineering, product, and all 
the other functions it requires,” warns Mike Brown. “The real cost is once it’s 
been built and is in production. That’s where you start to see the real cost, 
because now you have something that can break. Everything that’s built on top of 
that feature is something that will have to [be taken] into account. So, in fact, the 
real cost happens after you ship.” Brown believes, as we do, that it behooves you 
to spend as much time upfront trying to gather information and data to guide 
your decision making and your requirements before you build anything. 


And industry-wide data backs this up: based on member data, the Institute of 
Electrical and Electronics Engineers (IEEE) estimated that fixing a software prob- 
lem after deployment costs 1oox as much as fixing it before development starts.” 


Brown has learned a tough lesson and now insists on prototyping on all new ini- 
tiatives. “As an example, this week we’re doing paper-level prototypes that we’re 
also testing with employees at the company. We’re asking, ‘Does this interaction 
make sense? Is there anything about this that you find puzzling?” Once this is 
done, we'll take it to another level of detail where we'll engage patients, and 
watch them use a particular interaction. This way, we can observe if there are any 
patterns, and if we can introduce them to our site to solve any problems.” 


Produx Labs CEO Melissa Perri echoes the sentiment that not enough discovery 
is being done at companies, large or small. “Some companies do this very well, 
but the majority of companies don’t do this at all,” Perri says. “They'll build an 





1 InVision, “2016 Product Design Report”. 
2 Robert N. Charette, “Why Software Fails”, IEEE Spectrum. 


3 This specific line of questioning isn't what we'd recommend in any user testing. Questions that are more 
open-ended and less leading provide better feedback. 
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MVP, and their MVP becomes the first version of the product. They don’t 
descope it. They don’t experiment. They simply build a first version and launch 
it. Often, they’re not measuring success on it. What’s missing is a logical step-by- 
step approach of answering the long list of questions the team has about the 
product before coding anything.” Perri feels companies are rushing to get some- 
thing to market, but they aren’t spending enough time understanding why it’s 
performing like it is. Avoid the expense of failure and product debt by doing as 
much lightweight testing as is reasonable. This is the best way to ensure that 
what you're building is going to be useful and usable. 


Closely connected to solving the right problem is talking to the right people. 
Knowing who to talk to reduces risk, but knowing what to talk about yields the 
most important value. Regardless of the domain, you need to know what specific 
problems your user is experiencing. You can only identify these problems by talk- 
ing to them directly, which requires designing the right interview questions. The 
right questions identify the problems they are trying to solve as well as whether 
those problems are worth solving. “That’s another big challenge that startups and 
new products have,” says Jim Semick. “Internally, they think there’s a problem, 
but the end user doesn’t perceive it to be a high enough problem on their priority 
list to solve.” 


Making the “fuzzy end” of the process less fuzzy means acknowledging that 
some of the things the product leader thinks are important may not be important 
to the end users. In the beginning stages of a product, the right conversations 
have little to do with product features, pricing, or onboarding. The best conversa- 
tions focus on thoroughly understanding the problem that you’re trying to solve 
and whether that is a problem worth solving. In other words, is this a problem 
important enough that your users or customers will exchange something of value 
(time, money, energy) to have it solved? 


You also have to deliver enough value that you overcome users’ natural inertia. 
Switching from whatever product or solution they use today has a real cost, so 
your solution doesn’t just have to be better—it has to be so much better it’s worth 
the effort to switch. 


Talking to the right people doesn’t actually mean you do all the talking. In fact, it 
should be the reverse. Asking the right questions is the right way to think about 
it and then listen to the answers without bias. “The best piece of professional 
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advice is actually the same piece of advice that I got from my mother growing up, 
but I think I was probably 25 before I realized what it actually meant,” says Mike 
Brown of PatientsLikeMe. “You have two ears and one mouth. Use them propor- 
tionally.” Listening seems to be challenging for everyone, not just product peo- 
ple. Consciously making the time to listen is a skill we could all be better at. Here 
are some easy ways to practice listening skills: 


e Start any conversation with stakeholders, users, and customers with the 
intention to listen, and wherever possible, the commitment to be the last 
to speak. 


e When someone has made an observation, provided feedback, or simply 
thought out loud, invite them to “tell me more?” 


e When you receive feedback that is suggesting a feature update or addition, 
respond by asking, “And how would you do that?” or “Show me how you 
would do that?” 


e Repeat back phrases to the person talking once they have finished to con- 
firm that you have heard what they've said. 


? 


“That’s something that I’m still working on,” says Brown. “Being an extrovert 
product manager who has to corral a lot of people, it’s sometimes hard to step 
back and listen, and so that’s something that I continue to work on in my own 
career. It’s easy to keep talking until the right words come out, but to really listen 
to what people have to say is even more important. You’re there to ask good ques- 
tions and take the feedback from a number of people. Using my ears and my 
mouth proportionally is something I think would serve me and other people 


well.” 


To Brown’s point, we might add that you have two eyes as well. Two eyes, two 
ears, and one mouth—using them in that proportion when doing user research 
is indeed a good lesson. 


Managing your team’s expectations 


Setting expectations helps teams to manage the tough times, and product leaders 
set expectations all the time. Successful product leaders, however, do it differ- 
ently. They focus on setting positive expectations. They discuss what they want 
from their teams, but they set expectations as part of a healthy, productive discus- 
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sion. The discussions are focused on what can be achieved, not on what can’t be. 
This is subtle but important. Telling your team what you don’t want from them, 
or that the product might fail if they do a certain thing, is the incorrect way to 
motivate them. Great leaders do not use negative expectations to motivate their 
teams, and if you are guilty of doing this, it’s time to stop. Failure is part of the 
game, and needs to be taken into account, but it should not be used as a threat. 
Failure that happens because teams are experimenting, learning, and pushing 
the limits is normal and should be expected. Using the threat of failure discour- 
ages people from doing the experimentation necessary to find solutions. We are 
human, and of course we realize that it hurts to let the company, users, and 
teams down. However, breaking a few plates along the way is how we learn to 
spin them. Don’t punish failure or experimentation. 


Knowing yourself 


From our interviews it seems like some leaders are better suited for the startup 
challenge than others. Working with a freshly minted product team certainly fea- 
tures as one of the bigger challenges for early-stage companies. “I have done 
both,” says Jeff Veen, Design Partner at the VC firm True Ventures and formerly 
VP of Design at Adobe and Google Analytics Team Lead. “I have adopted existing 
teams as well as built teams from scratch. I have never really been successful 
with an adopted team. It’s always been creating the team from scratch that works 
best for me.” Veen, who cofounded TypeKit and Adaptive Path, the ground- 
breaking user experience firm in San Francisco, admits that he’s drawn to 
startup teams because he finds it very hard to work with established teams. He 
prefers to select a certain balance of people to pull together into a team, and 
adopting an existing team doesn’t allow for this precision—“So stepping in as a 
leader in an existing team just never worked for me.” Veen’s experience isn’t 
unique, and possibly not even restricted to startups. Adopting or joining existing 
teams is often about merging cultures and styles. 


This can be challenging for any team, so finding the right leader is critical. It’s 
essential that the leader knows their strengths and admits where they might lack 
patience, hard skills, and soft skills. Cait Porte, VP of Product at Zmags, embod- 
ies the type of self-reflection and awareness that makes the difference in great 
leaders: “I would probably say patience is a virtue. I tend to be somebody who is 
always going, always looking for the next thing. I’m very driven, very motivated, 
really energetic, and I like things that can happen right away. I want them to hap- 
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pen yesterday. As I’ve grown in my product career, I’ve realized that sometimes 
patience is really, really valuable because you can get more feedback, you can 
digest things a little bit better. When I think back to my early product career, I 
wouldn’t understand why we weren't getting something done faster. Why is it 
going to take us so long to do XYZ? As I’ve grown into this new role, and 
watched myself evolve and watched others evolve, having patience has become 
increasingly important, particularly as a product manager, to show me that 
there’s a lot more complexity than ‘build this feature, get it out the door, and then 
build the next one.’ I would probably tell myself to just be a little bit more patient, 
both with process and with people.” 


For the product leader, it’s important to figure out where they can add the most 
value. What situations appeal to them? Does an early-stage company suit their 
character and style? When are they doing something that comes naturally to 
them, and when are they trying too hard to adapt to a role that doesn’t suit them? 
We've all witnessed this, either in others or in ourselves. An extremely small set 
of leaders can be both startup gurus and leaders of a mature product organiza- 
tion. 


STARTUP PRODUCT LEADERSHIP STYLE 


As we write this book, the modern tech product space seems to be going through 
its teenage years—awkward, confused, and frequently suffering from confidence 
issues. It’s not an easy time for leaders to know how to lead. It’s hardly surpris- 
ing considering that the last few decades have been dominated by companies led 
by charismatic leaders like Steve Jobs, Bill Gates, and Larry Ellison. These vision- 
ary personalities, and their autocratic styles, are the mythologies that younger 
product leaders have grown up with. Walk through any airport, and you'll find 
the newsstands stacked with books on how these masters of the tech realm led 
their companies to success. The problem with this industry-hyped image of the 
product leader is that in the decades since these media darlings dropped out of 
school to start their companies, a lot has changed. 


The hardware, software, and internet world that the product leader now lives in 
looks very different from the technology landscape in which the original product 
managers grew up. Following this rollercoaster transition has been the evolution 
of the product leader’s career. 
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Fortunately, there is a significant cohort of product leaders out there today to 
make these transitions easier. With these changes, the complexity of the job has 
skyrocketed. It is no longer enough for market leaders to simply design a cooler- 
looking box for their devices; they have to reach ever deeper into their customers’ 
lives and solve more complex, and often hidden, problems in order to add value. 


ALIGNING PRODUCT VISION WITH STRATEGY AND TACTICS 


Without doubt the largest challenge for any organization and any leader is align- 
ing the vision with the day-to-day work. For startups this can be especially chal- 
lenging, purely because they are still trying to figure out their vision. It’s not 
necessarily the job of the product leader to determine the company vision, but it 
should be. At the very least, the product leader, and their team, should have the 
ability to strongly influence the vision and direct it on the basis of their ongoing 
work. However, there is a significant difference between those jobs that are 
responsible for strategic product vision, and those that are largely tactically 
focused. In startups this might not always be the case, but it’s a reality those lead- 
ers have to deal with every day. Furthermore, in any product organization most 
of the people that work there will have a tactical job. This means that even when 
a product leader can’t influence the vision, they will certainly be responsible for 
communicating it to their teams. The challenge the leader faces is making sure 
that everyone is aware of the strategic vision and what it means to their tactical 
choices and decisions. In a startup it falls to the CEO of the company and the 
product leader to translate what the strategy means to the product team and how 
it will be implemented at the tactical level. 


To make this possible you have to start with this question: are the vision and 
strategy going to have any impact on the organization? Unfortunately, for most 
early-stage businesses, this might not be the case. The vision and strategy of an 
individual product leader or product development team really won’t affect the 
overall trajectory of the business. So you have to go back to the origin story. You 
have to ask: Does the company know enough about this new product, and what 
will be its real impact on the customer? Is the company capable of putting func- 
tions like sales, marketing, customer success, operations, and engineering in 
support of the product? If that checks out—if the organization is committed to 
doing that—then strategy and vision can be made to work at the tactical level too. 


For the product leader it’s important for everyone to get aligned around the 
vision. For that to happen the vision and the strategy need to be grounded in real- 
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ity. This means the strategy needs to be tied back to unit economics. To under- 
stand unit economics, you first need to understand whose behavior you’re 
measuring. Cost of acquisition (CAC) tells you nothing about the value of the 
acquisition or the long-term requirements of that acquisition. It merely suggests 
the financial cost. Getting to know the customer is a step that many startup prod- 
uct leaders skip in their haste to measure something. 


Mapping the vision 


Translating the vision into an experience map, roadmap, or product map is part 
of the job. How, then, can you take the vision and make sure there are steps 
along the road to achieve it? The challenge here is to ensure that during the 
translation, the decisions that go into the work remain connected to the vision. 
When tactical teams are working on product roadmaps, it’s easy to lose sight of 
the overall vision. For example, Tesla started its business by positioning itself as 
an energy company for the future. Unfortunately, that big vision can get easily 
lost when the product manager on the factory floor is worried about shipping a 
single component of the car’s software. Decisions that are made about what gets 
onto the product roadmap are sometimes disconnected from the strategic goals 
of the organization. 


A well-mapped and communicated vision will include the following elements: 


A timeless description of what value the organization aims to deliver 
(remember Disney’s “Make People Happy”) 


e Avision disconnected from specific technology or trends 
e Separate documents to describe the user goals and the product goals 
e A roadmap of what the big themes or stages of product delivery will be 


+ Connections between the stages of delivery and the value being delivered 


The physical form that your vision and roadmap take is less important than what 
they include. Thinking through these steps is almost always more important than 
the specific output forms. 
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Communicating continuously 


It’s really important for product leaders to work with stakeholders (investors, 
founders, board members, key employees, core customers, and partners) to 
understand their priorities and get buy-in from them on the things the team is 
going to accomplish this period. Once there’s clarity around the vision, product 
leaders must work with these stakeholders to define the initiatives that will fit 
those strategic goals. Rather than a product leader or manager operating in a vac- 
uum and unilaterally creating this product roadmap, they engage in a co-creative 
process that solidifies the vision and aligns the team. Roadmaps are just the out- 
put of a conversation and an agreement—and this conversation may need to hap- 
pen several times during the evolution of a product. Roadmaps are not supposed 
to be set in stone. As with most things in leadership, they’re an exercise to get 
people talking to each other. 


Good product leaders today work alongside their stakeholders or, at the very 
least, keep their stakeholders regularly updated. This continuous communication 
needs to err on the side of overcommunication. They break down silos and open 
channels. They look for buy-in all along the way. This also means they take the 
time to educate their stakeholders and executives. Updates and education don’t 
have to be big things, either—it might simply mean informing the executive 
team that a feature agreed on six months ago is no longer valid because circum- 
stances have changed. Maybe some new competitive information was uncovered, 
or maybe the development effort that seemed likely at that stage didn’t material- 
ize. Educating or reminding the stakeholders that things in this Agile world are 
going to change is key. As Jim Semick says about communicating expectations to 
executives, “In the next two, three months, I’m fairly certain about what is going 
to get delivered. Beyond that, we have an idea, but it’s not set in stone.” 


It might be clear that product leaders need to do a good job of setting and manag- 
ing expectations for their stakeholders, but it requires regular communication. 
Unfortunately, regular communication isn’t the norm, even in small companies 
and teams. In all our interviews we noticed that the most successful product lead- 
ers were also those that were regularly and actively communicating to all parts of 
their product organization, their users, and their outside partners. The organiza- 
tions facing the worst problems had a culture of poor or infrequent communica- 
tion. Unsurprisingly, we also observed that there is no single communication 
structure that works for all; every organization has their own style. Whether that 
communication is done through formal meetings with the stakeholders, daily 
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standups and monthly meetings, or informal catch-ups, the key is to open up the 
channels. Perceptive product leaders will also craft channels for the different per- 
sonalities within the organization. Here are some suggestions: 


+ Detailers will get detailed reports. 
e Analyzers will get options and reasons for choosing one or the other. 


e Producers will get brief but frequent updates and decisions. 


Other techniques involve the “show and tell” approach: 


e Prototyping demos 
+ Providing walkthroughs of new product features 


e Standing in front of a wall-sized experience map to make sure everyone is 
seeing the latest thinking and feedback 


Whatever the style of communication, one thing is common across successful 
organizations: communication is constant. 


PLAYING THE CUSTOMER TO DISCOVER CORE VALUE 


At the beginning, product leaders wear all the hats, and one of those hats should 
represent the customer. In the absence of a finished product, or even a prototype, 
the product leader may find themselves answering for the end user. This means 
that the startup product leader’s style must also be flexible enough to ignore their 
subjective opinions or views and embrace the views of the customer without bias. 
This is difficult, especially when you're an early-stage product with little or no 
data to back up qualitative perspectives. 


Many founders believe they are the customer. This is dangerous. The role of the 
company is to reflect the customer’s needs back to them, not construct them out 
of the founder’s subjective experience. This is both the story of the product value 
and the resulting brand. “You don’t invent the brand; the customer invents it and 
then you just reflect it back to them,” says Jeremy Bailey, Creative Director for 
Product at FreshBooks. 


In early-stage businesses it’s relatively easy to create a theory about who their 
customers are. To understand whether the business will go beyond theory 


122 | PRODUCT LEADERSHIP 


requires getting down to bedrock. As an early-stage startup you must have an 
urgency to get out of the theoretical customer comfort zone and find out who 
actually pays you money. This can only happen if you’re getting out and testing 
prototypes and early versions of the product. 


Once you've figured out who pays you, you need to figure out who uses your 
product. It’s rarely the same person if it’s a B2B product, and can often be differ- 
ent people with consumer-focused products. Think about parents buying prod- 
ucts for their kids or even their own aging parents. Along with finding out who 
pays you the money, it’s important to understand who influences the use of your 
product and who evangelizes your product. In complex product sales the person 
buying from you (e.g., line manager) may not be the person paying you (e.g., 
finance department), let alone the end user. If that’s not complicated enough, 
you must also keep in mind that none of these personas are mutually exclusive. 
A buyer can be a customer and a user, or they can be three separate people. 
While all of these personas are important when you map out your initial product 
strategy, prioritizing them is also key. Unsurprisingly, finding out who your 
users and customers are gets to the core of your business value. Mapping this 
value allows you to determine the best metrics to measure your business. Only 
once you know where the value flows to and from can you know which unit eco- 
nomics to use to measure the product’s success or failure. 


For startup product leaders to get to the point of selecting the right unit econom- 
ics, they need to talk about the end state and decide which elements of the work 
need customer input. Not everything needs a user’s feedback, but high-priority 
features and interactions should be on that list. If you’ve been working in estab- 
lished product environments, then this is a mental adjustment you have to make 
when you go back to early-stage or free customers. “If you’re used to design and 
systems that depend on the customer to work, how do they work when you have 
no customers?” asks David Cancel of Drift. “In that case, as a leader, and not just 
for myself but for the rest of the team, we had to make some hypotheses and had 
to almost play the customer a bit to get a bootstrapped system.” Cancel believes 
that these small stepping stones allow the product manager or leader to level up 
through the process and add the appropriate user inputs when the time is right. 
Once the product rounds the corner and you're dealing with real beta users, then 
the daily users would be the proxy for customers. The next step beyond the daily 
customers is to find and study the diversity of real customers. Although this pro- 
cess to understand the relationship between the user and the product never really 
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ends, it gets to the point where the product leader can delegate the learning to 
their team. “So, little by little, as we get whatever critical volume means to our 
business—for example, the number of customers—then we can stop, take our 
hands off things, and let the team start to run things with real customer input,” 
says Cancel. This process reveals the value stream, and that in turn reveals the 
path ahead for the product leader. 


How startups think about their relationship with their first customers and users 
can be design-driven too. Knowing your customer also means knowing what 
experience design and visual design will connect them to the product experience 
in a meaningful way. Developing a strategy in terms of whom they are designing 
for is the cornerstone of many startups. Ally Shear, cofounder and Head of Prod- 
uct at ANSWR, a Boston-based knowledge sharing and collaboration solution for 
teams, describes its approach like this: “It starts with understanding our users— 
how we want to work with them and what motivates them.” The styles and fea- 
tures of the product not only communicate the startup’s solutions, but also signal 
where the startup wants to be categorized. “I fundamentally believe that if I look 
at companies that have a strong brand or identity, they carry those identities not 
only from their corporate-facing websites but through their product lines as 
well,” observes Shear. This continuity between the proposed solution and how 
the company displays that solution is something that Shear believes matters to 
the end user. “They understand who you are whether they’re reading a blog post 
or actually using your product. If you strive to have that continuity across every- 
thing, then you've really achieved something significant.” 


As we've described, getting to an understanding of your customer or user prob- 
lem is critical to success. It’s our opinion that one of the reasons developing a 
customer roadmap is so difficult is because product teams don’t spend enough 
time with their end users. A lack of discovery time leaves gaps in the knowledge 
necessary to craft a clear path forward. Whether you call it customer discovery or 
problem discovery, going through this process to understand the user is a sure 
path to success as a modern product leader. The insights revealed through user 
interviews and conversations add clarity, and each new insight refines the inter- 
view questions and produces better responses. “By the time you’re talking to your 
roth or 15th prospect, you can describe the problem to them,” notes Jim Semick. 
“The best part is, they’re agreeing with you.” Using qualitative conversations to 
truly understand the problem provides a clarity that makes the quantitative 
aspects of gathering data more effective. Before rolling out any proposed solu- 
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tion, the product leader should have confidence that the problem is well under- 
stood. Semick reinforces this point: “It’s only then that you can present the 
solution to that problem to your customers and users. That solution can be the 
product, or the prototype, or whatever it is you have for them.” 


Don’t skip the research 


Product startups or early-stage product projects often miss this first key step of 
understanding the problem. They are in too much of a hurry to build features or 
screens that haven’t been validated. As we’ve said, not understanding the user 
experience leaves gaps in knowledge that lead to frustrations around planning for 
the future. If product leaders invest time and energy into knowing their audience 
and developing the personas to adequately describe them, they will reduce the 
ambiguity. Only then can you move on to customer development, the process of 
really understanding the product and whether or not it solves the needs 
described by the users. Once both these steps—understanding the problem and 
understanding the solution—have been achieved, the product leaders can move 
on to next steps like deciding what the MVP (minimum viable product) will 
include or how it might be priced. 


It bears repeating that overcoming the ambiguity of what to build and when to 
release features can come only from understanding your users. Knowing what 
their problems are, and being able to clearly articulate them, leads to better per- 
sona clarity. Once you have mapped your personas and validated your core value 
against actual revenue, usage, and utilization of your product, then you’re able to 
map one-step, two-step, three-step adjacencies in your strategy about what mar- 
kets, new or emerging, to go after. What new products should you chase? What 
new geographies do you go after? It becomes increasingly clear what not to do, 
and what low-hanging fruit you should go tackle. 


RESEARCH, DATA, AND TESTING 


While startup product leaders may initially need to step into the shoes of their 
customers and users, they can’t be a wholesale replacement for quality research 
and solid data. These sources of information include the interviews we described 
in the preceding sections and validation in the form of testing with real product 
examples (e.g., prototypes). There are too many tools, environments, industries, 
and user types for us to deal with that here. What we are interested in as product 
leaders is the outcome that the research will provide. The obvious next question 
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is how do research and data guide the early product vision and the company 
value proposition? 


Making research accessible 


“One of the things that we’ve been working harder to do is to get research into 
the hands of the rest of the team in digestible bits,” says Josh Brewer, CEO of 
digital product design firm Abstract, and previously Principal Designer at Twit- 
ter. “Getting the team exposed to that data was the first order. They’re starting to 
see and pick up the tone, if you will, of what we’re seeing in the big aggregate set 
of data.” Brewer's deliberate efforts to make research understandable before 
dropping it into the laps of his team supports the best practices we’ve observed. 
Simply dumping research or data onto a product team has no value, and may 
even become an obstacle to product improvements because it takes time to 
understand and digest. This does not mean that leaders should be filtering the 
research through their own biases or preferences, but rather that they should 
identify vectors by which they can deliver the insights to the team. Each team will 
need to determine which vectors or communication channels they prefer. Data is 
becoming more accessible, but that doesn’t necessarily solve the problem of qual- 
ity. Ideally, the importance of the information being shared will determine the 
delivery vector. For example, qualitative data from customer interviews is best 
delivered in forums where team members can ask questions and get additional 
clarity. Broader market research could conceivably be delivered without face-to- 
face discussion. 


To start with, early-stage product leaders need only the most important qualita- 
tive data to point them in the right direction. It’s very rare that companies require 
enormous amounts of research to do basic validation of their product/market fit. 
“We’re trying to understand what the customer’s main pain is so we're able to 
clearly articulate that,” says Brad Weinberg of the earliest stages of product cre- 
ation. Weinberg is cofounder of Blueprint Health, a New York-based healthcare 
incubator that has stewarded dozens of product startups through the early phases 
of their growth. The job of the startup product leader is to explain how their busi- 
ness can potentially solve the user’s problem and whether you have agreement 
with the client. “In the beginning all you need to create is a high-level plan,” says 
Weinberg. This is step one for Weinberg and his teams. In this high-level plan 
there are a handful of questions that need answers before you can move on: “Ask 
the customer what their pain point is, what their current problems are, how they 
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try to solve those problems now, and how you might solve them differently. Sec- 
ond step: go run that by them.” 


Cycling through these steps might require a few iterations. Feedback from poten- 
tial customers might alter how you present the solutions or identify new per- 
sonas. Weinberg continues that the point of this simplified back-and-forth is to 
find out whether you can solve those problems, and whether the customer would 
buy the solution. The third step, according to Weinberg, is to take the people that 
expressed interest in buying the proposed solution and refine that solution. He 
recommends making something the prospective customer can start to see, touch, 
and experience: “Build some wireframes and some mockups in parallel.” In this 
initial stage the product leader is focusing on the basic functionality, like how the 
wireframe solves the user story. The artifact is not the object; rather, the response 
to the object’s suggested solution is where the product leader needs to focus 
attention. By building basic design mockups you’re validating the earlier rounds 
of thinking. This is not intended to convert these testing audiences to paying cus- 
tomers but rather to validate that intention. This interview-build-validate cycle 
can be repeated as many times as necessary until the team has established a risk 
level they are comfortable with. In other words, does the team feel they have 
enough feedback to elevate the conversation to the next version of prototype? 


Prototyping is one way to help you define and harmonize internally as you do 
concept testing. Fighting for prototypes to be used as a core part of the testing 
strategy is part of the product leader’s responsibility. As you start putting proto- 
types out into the market and getting them into your product, the challenge 
becomes, how you do qualitative user testing and research—whether it’s the 
research before you actually decide to do anything, or once you’ve put it in the 
product? “We do user research in lots of ways,” says Emily Rawitsch, Senior 
Manager for Project Design at Spotify. “Sometimes we’re doing early concept 
testing at a high level, and sometimes we’re testing an early concept before it’s 
being developed. Other times we’re testing a concept while it’s being developed, 
and then sometimes we’re getting research after it’s been in the wild. When it’s 
early concept testing, that’s often when we’re moving fast, kind of like in design 
sprints. Although in our company we often call it design swats, kind of like a 
SWAT team or a group of specialists coming in to solve this urgent problem.” 


Attacking this early concept testing research SWAT-style gives Rawitsch’s team 
the speed they need to answer their problem statements. “We’re trying to move 
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fast because we don’t have a lot of time,” she explains. Balancing the need to 
move quickly while ensuring they are not leaving any of the other product team 
members behind is a delicate balancing act: “We can’t stay that far ahead of the 
sprint, and the developers are itching to go. More often than not, we’re doing this 
in four or five days. To give you an example of what that hyper-speed research 
looks like, we just did this two weeks ago where on day one we were exploring 
lots of solutions with divergent thinking. Day two is where we regroup with the 
engineers and product managers to converge ideas and kind of figure out what 
we're really trying to learn. Day three, we’re finalizing our prototype and recruit- 
ing actual users and scheduling sessions, and putting together a moderation 
guide. By day four, we are talking to five to seven users for 30-minute sessions, 
and before we leave the office that day we’ve had our research debrief and 
emailed our top findings. At that point we’re ready to keep running with the 
coded prototype.” 


The point of doing this type of research is to avoid having to build out an entire 
product only to discover that nobody cares for what you’ve created. Writing out 
product features in excruciating detail before basic testing is avoidable too. There 
are too many assumptions early on. There are sometimes assumptions about 
assumptions. Until these assumptions can be identified and resolved, any prod- 
uct creation is just guesswork. Some might argue that best practice and the prod- 
uct team’s previous experience might overcome these gaps in knowledge, but the 
reality is that they will never be a good substitute for in-depth research. Whatever 
the situation, the product leader will need to make tradeoffs and decide what 
research solutions to spend their time, money, and energy on. 


Prioritizing goals 


Assuming that the product leader and their team have done the necessary work 
of getting end-user feedback and supporting research, the next challenge is 
knowing what to prioritize. In other words, which of the unmet needs will get the 
attention of the team? “There are two answers to that,” says Josh Brewer. “One, 
there’s always an initial set of things for any product. We identified very early on 
that there were a couple things that absolutely had to exist. Otherwise, nothing 
else would matter.” Research or initial market fit testing will always generate a 
list of core items. “Two, if you don’t do X, all of the things that depend on X in 
the system don’t exist. So guess what? That one thing becomes one big risk.” 
Brewer uses this simple two-step model to identify things that need his team’s 


128 | PRODUCT LEADERSHIP 


attention. Either it’s a core item or it’s a critical element that other core items 
need in order to exist. Finally, Brewer runs through the list and asks how the 
team can test these things. “Aside from those core pieces, because of the research 
and the methodology that we’ve used, they’re resulting in a scoring mechanism. 
Were able to say, ‘Wow, OK. There’s four unmet needs that are at the top of the 
scale.” 


There is prioritization around what needs the product is solving, but then there’s 
the implication for the product development life cycle. After prioritization, it 
becomes a gating function. The reality is that even after items have been priori- 
tized, there’s often still a suggestion from executives, founders, or possibly HIP- 
POs (highest paid person’s opinion) to include more items on the list than time 
might allow for. 


In some cases there’s no way around the fact that something has to get done. 
Brewer describes such a scenario: “We have to do all of them, period. And we 
have to go heads down, and we have to go work through these. And then we have 
to figure out how to put them together and how they relate to each other.” While 
we don’t recommend giving in to every request that comes along, we do like the 
idea that this triggers new conversations. How you structure those conversations 
will be dependent on the team structure and processes you use. There is no ideal 
way to have conversations about priorities, but it is a requirement to have these 
conversations frequently and without politics. “It’s a mix of longer-term evalua- 
tion and working with the team to get feedback on initiatives that are in current 
sprints,” says Rose Grabowski, former Director of Product Management at 
Invaluable. “Also, looking at bugs that come in and trying to make connections 
between issues that are happening. There’s definitely a variety of high-level and 
very granular type things day to day. That’s the life of a product person, right?” 


Balancing priorities and embracing tensions 


There’s always some tension, healthy or otherwise, between overall company 
priorities and the specific product priorities. When you’re building the company, 
you have to be thinking about a wide range of things, like fundraising, so that 
you have a runway for everything else to happen. Those things might impact or 
change what you are actually doing on the product side. The most common ques- 
tion product leaders have is, how do you balance that tension? Product leaders 
should always have a place for prioritizing suggestions resulting from these con- 
versations about features and ideas. Most people just want their idea heard and 
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valued. Of course, there will always be too many ideas. We suggest creating a car 
park or a backlog for these product ideas. This can be maintained as a white- 
board, as a series of Post-its, or in a company Slack channel or idea management 
tool. If everyone knows there’s a place where their idea will be stored, considered, 
and not discarded, then most of the time these conversations are much, much 
easier. 


“I’m right in the middle of it because my goal is for this to be a profitable com- 
pany,” says Brewer. “Were building something that we intend to charge for and 
we believe it will be valuable. We have a lot of stuff to validate on that front, but 
that’s the work. We also have a runway, and we know where the end is.” Brewer 
is describing a scenario very familiar to startup and high-growth companies. 
These constraints and tradeoffs are part of the leader’s job. Instead of avoiding 
these decisions, great product leaders acknowledge the reality and embrace them. 
Brewer sees the tradeoffs and implications as an opportunity to drive the advan- 
tages of good process. “Given the amount of time, the number of people, and the 
skill sets that we have, let’s establish a framework to make decisions around what 
we do and what we don’t do.” The decisions will be constrained and guided by 
things like the vision of the company, what the team believes this product should 
be, the skills of the current team, what’s missing from those skills, and some 
level of prioritization. 


From that framework, a product leader will be able to cluster things into the vari- 
ous categories of prioritization and start to scope those out. Brewer's goal is to 
have a complete picture of what the team wants to do so he can break it down 
and say, “OK, we probably can’t do all of this, but how can we build the right sys- 
tem that grows into this? And do we all agree, at least right now given all the data 
we have, that this is what we want to grow into? Yes? OK, great. Let’s go.” 


Diving deeper on what to prioritize 


We've heard from the top product leaders that one of their greatest fears is that 
they find themselves working on the wrong thing. A team might spend weeks, 
months, or even years trying to fix product problems, and then realize they are 
either the wrong problems or that things are out of their control. “If they had lif- 
ted their heads up a little bit, looked over, and spent time understanding the 
user’s problem, they might have realized that actually, there isn’t a product prob- 
lem if we take that away and replace it with whatever,” says Brewer. 
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“A lot of times, startups in technical spaces—the medical world being one of 
them—are very engineering-heavy,” says Brad Weinberg of Blueprint Health. “So 
the mindset is about knowing what the functionality needs to be, but not really 
knowing what the user experience is going to be.” Weinberg believes product 
leaders need to be able to think at the level of the user story. To know what to 
prioritize, a leader must operate at the level of solving problems rather than at 
the level of functionality. “[Product leaders] are getting people to think,” says 
Weinberg. “It’s the same thing as engineering, but in a different way. Engineers 
are doing it because they know code and they know engineering really well, and 
the product people are doing it because often—as businesspeople that haven’t 
built products before—they are thinking of features.” Weinberg says it’s about 
asking the right questions so the team will focus on the right activities. “What’s 
the way to solve this? What’s the way we can accomplish this from a design and 
an engineering perspective, in an efficient manner, and at the same time, solve 
the core question of the problems we have?” 


“Part of that process is also socializing that information in lots of different ways,” 
says Placester’s Fred Townes of the prioritization process. “Our breakout ses- 
sions start with saying: ‘This is what we did. This is what we learned. We agreed 
this is important. This is how we’re doing it.’ There’s lots of straightforward com- 
munication.” Many of the leaders we spoke to talked about the importance of 
good communication. For most of them this seemed so obvious they didn’t make 
a big deal about it, and it can be overlooked. Junior managers or first-time leaders 
might assume that good communication happens naturally. However, as we’ve 
outlined earlier, good communication takes consistent effort. 


Researching and reprioritizing 


Product leaders can learn some surprising things in research, things that make 
them reconsider or deprioritize an item that their team was going to work on. 
This insight results in a reprioritization and in some cases puts the item on the 
back burner. 


Emily Rawitsch from Invaluable tells the story of a reprioritization because of a 
change in initial assumptions about the product idea: “There’s one that really 
blew my mind. We wanted to redesign how search results were presented on the 
website. Today they are presented in a listview.” Invaluable is a premium auction 
site, so in many ways the business model and user experience is similar to ecom- 
merce experiences. “But there are definite differences because we have a detailed 
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description and a condition report,” Rawitsch continues. “People want to know if 
there’s a chip in an expensive vase, or they want to know the estimate, so there’s 
a lot of information. We looked at several mental models or expectations of how 
search results are presented on most shopping or ecommerce websites, and usu- 
ally, it’s a beautiful grid view of images.” 


Based on user research, Rawitsch’s team knew that customers prefer to see large, 
high-resolution images. After all, this is an auction site for high-value items. “We 
figured, since our users love images, let’s test out a gridview.” Initially the team 
was prototyping, as Rawitsch wanted to make sure they tested the concepts 
before they started development. “We did it using InVision, trying the idea that 
we could give them a listview and a gridview. We probably talked to 10 or 12 peo- 
ple in the end.” The team initially thought that the gridview would work best, 
because of the high value the users had given to images during research. What 
was surprising was the reaction from the users. They didn’t like the gridview. 
“They were not wowed by it, and we really thought that they would be. Our 
hypothesis was that they would want the gridview because they could see more 
items at once, which is what they expect when browsing the web for shopping.” 


The lesson here is that what works elsewhere may not work in your context, and 
prioritizing based on new user research is key. Prioritizing based on gut reaction 
or assumed interactions might not end up as expected, as Rawitsch discovered: 
“Many of the users said it was harder to compare and contrast the information, 
as they could no longer skim down the page to compare the estimates or the con- 
ditions. Instead, their eyes had to zigzag across the screen, and that made it 
harder. That definitely surprised us; we weren’t expecting it. It doesn’t mean that 
we won't ever implement this because, keep in mind, we talked to existing users 
who also have a bit of bias because maybe they don’t want the site to change. 
They are used to how it is. We didn’t talk to potential new users, but at the same 
time, because nobody we talked to was jumping up and down for the feature, we 
knew that we could deprioritize it and focus on something that might bring more 
value to our user base, faster.” 


Product Founder Versus First Product Hire 


Ideally, every startup has a product leader as a cofounder, who owns the initial 
vision, strategy, and execution of the product. Inevitably, though, there comes a 
time when that founder runs out of time or experience in scaling and growing a 
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product function, and needs to hire a more experienced product leader to take 
the reins. This is especially true when the product founder is also the CEO and 
the responsibilities of that job—from managing other teams to fundraising to 
managing the board—start piling up. 


“The only time I had the opportunity to be a founding CEO of a small team, I 
was also a product manager. I had spent the good part of two, or two and a half 
decades telling people to validate, to check with customers, to watch the market 
and think before you build,” says Rich Mironov of balancing CEO tasks with 
product leadership tasks. “I was so wrapped up in fundraising, HR, real estate, 
payroll, hiring an engineering team, and all the things that CEOs do, that Pd 
actually postponed checking if anybody wanted the product. Not completely sur- 
prisingly, no one wanted the product.” Mironov’s lesson is a harsh one that many 
first-time founders and CEOs learn the hard way. “It renewed my deep apprecia- 
tion for the job that CEOs do, which I never want to do again. It humbled me and 
made me more empathetic toward folks who are focused on the quarterly bottom 
line.” Mironov reminds us of the reality facing product founders. “My takeaway 
here is always that it’s really easy to tell everybody to think about jobs we solved 
and to validate in the market, listen to customers’ voice, and write endlessly, but 
in practice, it’s both really hard to do and easy to justify not doing.” Founders 
must ask the tough questions about who will lead the company and who will lead 
the product. 


If founders are willing to pass on the product leadership role, they will need to 
hire for the appropriate stage. Many first-time founders are tempted to go find 
the most experienced product leader they can, but hiring too senior, too quickly, 
can be a mistake. “When you're hiring your first product manager, don’t hire a 
VP of Product,” says Ken Norton of GV. “Hire a great product manager and give 
them the space to grow into your VP over time as the team grows, but with the 
understanding that if they can’t make that transition, you will eventually need to 
hire a strong VP to take the team to the next level.” 


Josh Brewer from Abstract agrees: “I’ve seen VPs of Product come in and have 
CEOs hand everything off to them—basically, like the future of the company’s up 
to them—which sets them up to fail. There’s no way that they’re ever going to be 
able to do that. It also relieves the CEO of that level of responsibility, which is, in 
my opinion, a very dangerous thing.” It makes sense to hire an experienced prod- 
uct manager who can grow into a leader and help take over the day-to-day execu- 
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tion of the product, but this naturally introduces a tension between the two 
product leaders. Who owns the vision? Who has the final say in product deci- 
sions? 


The key, as always, is to be crystal clear about responsibilities and communica- 
tion expectations upfront. Brewer continues, “The best way to do that is to spend 
time developing the relationship between those two people.” As is true of work- 
ing with any other stakeholders, spending time developing the communication 
style and habits between the founder and product leader is crucial. “How do we 
know if we’re successful? And do we agree on that? Because if you are the prod- 
uct manager and you think success is A, but I’m the CEO and I think success is 
B, we’re in trouble. You have to constantly work to answer those questions, 
which is funny, because they’re not even about the product. To some degree, 
they’re about how we work together, how we communicate.” 


In situations where none of the founders have strong product backgrounds, it is 
essential to find, as soon as possible, an experienced product leader who can set 
and own the product vision for the company. As we’ve outlined, no startup will 
succeed without a clear and cohesive product vision, definition of success, and 
ability to execute toward that vision. 


Startup Product Teams 


Building the startup product team can be one of the most challenging things a 
product leader can do. In many cases, the startup is still trying to understand its 
position in the market and its value proposition. Hiring for a team that isn’t 
entirely defined can be difficult for first-time product leaders. Some leaders thrive 
in this environment, while others struggle with the ambiguities associated with 
startups. Several of the product leaders we interviewed had worked in both 
startup environments and in larger corporate environments. This makes their 
perspectives particularly interesting because they are able to share insights on 
how these situations are different. Some differences boil down to management 
style or personal preference, while others are germane to the specific stage of the 
company. 


In this section we consider what makes building a startup team unique, what to 
look for in an ideal team member, and what dynamics you should be preparing 
for as the company grows. While it’s obvious that no business or product is the 
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same, patterns do exist, and generalizations can be made about certain elements 
of team building and management. 


WEARING LOTS OF HATS IN SMALL TEAMS 


Product leaders at small companies, or startups with small teams, need to wear 
lots of different hats. They tend to bounce around from product design and devel- 
opment, to strategy, to managing the team on an hour-to-hour basis. Unlike their 
bigger corporate siblings, small teams don’t always have a schedule of what they 
need to work on each day, and neither can they rely on enough resources for each 
team member to be a deep specialist. Customer feedback at startups can quickly 
reprioritize work efforts. One minute you're talking about a feature roadmap, and 
the next you’re putting out a fire related to a new bug. This ambiguous work 
environment isn’t for everyone. Being able to bounce from one set of activities to 
the next requires a special kind of leader and a special kind of team. 


Regardless of the size of a company, small teams appear to work better than large 
teams. This doesn’t mean the company should remain small, but it does mean it 
might be worthwhile to break the company into smaller team sizes. Our research 
and experience indicates that other high-performance teams share our prefer- 
ence. The rapid adoption of Scrum and Agile methodologies seems to reinforce 
the concept that smaller teams operate better, as does Amazon’s two-pizza rule* 
and other anecdotal evidence.’ For Richard Banfield’s 2015 book Design Leader- 
ship, more than 85 design leaders of digital design teams and firms were inter- 
viewed, all of whom affirmed that the optimal size for regional offices is 25-40 
people. In the military, Navy SEAL teams are generally organized into troops of 
about 30-40, but some teams have as few as 18 operators. SEALs are task- 
organized for operational purposes into four squads of eight “fire teams” of four 


to five people, a size that allows these working groups to remain nimble and 
flexible. 





4 In response to the problem that attendees in large groups tend to agree with each other instead of voicing 
their own opinions and ideas, Amazon's Jeff Bezos proposed a solution he calls the “two-pizza rule”: 
Never have a meeting where two pizzas couldn't feed the entire group. 


5 William Allen, “Never Stop Talking: How Small Teams Stay Great When They Grow”, 99U. 
6 Check out the book's website for more information. 
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Managing team dynamics 


“We're very small, so although I do some one-on-one work, generally speaking 
we work together as a group,” says Ally Shear of ANSWR. “When we’re doing 
higher-level design it’s usually done as a group, but when we get down to details, 
it’s more focused—for example, exploring whether we want to include this drop- 
down, or this element, or that style, tends to be decided on a one-on-one basis.” 
Shear is describing the typical startup group dynamic. Teams like this can morph 
from one-on-ones to very small groups to larger groups on an hour-to-hour basis. 
That means leaders need to be able to go from manager to mentor and then back 
to manager in a moment’s notice. This back-and-forth requires strong communi- 
cation skills. Living in a bubble is not an option for product leaders. Jim Semick 
believes that product managers need to develop these skills to manage the 
dynamics of startup life: “They have to have the communication skills and the 
political skills to know who to talk to, and how often to talk with them.” 


Startups employ fewer people, so communication between team members can be 
as easy as swiveling a chair around. As the teams grow, the luxury of easy com- 
munication can turn into a logistical nightmare, especially for distributed teams 
who may not be in the same location. Being in different locations has obvious 
challenges. Collocation is preferred, but as teams embrace remote working prac- 
tices, it is now less common. The upside of an expanding team is that more peo- 
ple are paying attention to the product and taking responsibility for it. The 
downside is an increased need for communication. This requires pretty crisp 
decision making to prevent tasks from stagnating and dragging out. Smaller 
teams don’t have the structured communication channels that larger teams have, 
so things tend to get done in a style that resembles the inconsistent nature of the 
environment they work in. One day or one week might be all about communicat- 
ing issues and finding solutions, while the next might be all about production or 
testing. 


“I spent all day yesterday in issues—all day answering questions and then 
answering more questions and poking holes in things and whatnot,” says Josh 
Brewer, who, in addition to cofounding Abstract, is coauthor of the highly popu- 
lar 52 Weeks of UX. “But we made enormous progress.” Brewer describes the 
back-and-forth that goes on in startups. One week his team will be heads down 
trying to get the fundamentals done, and then suddenly all the issues they’ve 
been working on reach the point where an entire day of discussion is necessary. 
A week of low-level communication can be leapfrogged when there’s a flurry of 
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solutions created by sudden communication opportunities. The dynamic has a 
variable cadence, but because of the small team size, a single day of intense com- 
munication can turbo-charge solutions and get blockages out of the way. Brewer 
says, when this happens, “a bunch of the work goes to engineering because it’s 
done and good to go, while other stuff is going back to the drawing board so we 
can take another pass at it.” 


Being able to facilitate and maintain agility in group structures is an important 
skill for product leaders. It shouldn’t be assumed that such skills come naturally 
to them, however. These kinds of people management skills are often taught and 
learned through experience, and are not innate characteristics. Experience in 
semistructured or timeboxed design thinking exercises can be very useful for this 
skill development. Training or exposure to design sprints, Directed Discovery, 
workshop facilitation, or deep dives gives product leaders the formal training and 
experience they need to manage ever-changing group dynamics. 


Aligning personalities and philosophy 


In a startup, it’s essential that you hire people who are respectful of one another 
and can adapt quickly. These qualities allow them to switch roles and responsibil- 
ities whenever there’s uncertainty. Dealing with the discontinuity of team 
dynamics and potential disagreements requires an open-mindedness and respect 
for other perspectives. Adaptability often means a product leader must hire peo- 
ple that are well rounded. Simply put, this means that they can take on roles and 
expand beyond what they are hired to do. An early-startup employee might need 
to step into a product leadership role one minute and then act like a sales rep the 
next. Frequently switching roles can be confusing and frustrating for some peo- 
ple, and it’s certainly not for everyone. You can determine whether someone is 
capable of this type of change by either looking at their track record or discussing 
how they have dealt with change in other aspects of their lives. “In my experi- 
ence, not everyone is cut out to work for a startup or at the early stages of a new 
product where you only know 80% of the answers because you’re never 100% 
certain,” says ProductPlan’s Semick. We'd go as far as saying that uncertainty is 
the domain not just of the startup world, but of all product companies. Daily 
swims in the ocean of ambiguity are a part of the product leader’s life—it’s just 
the depth that changes. 


Hiring this flexible personality type means product managers and leaders get 
more out of their teams. “I’m usually looking for people who are multidiscipli- 
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nary in their background, and in the way that they approach stuff,” says Josh 
Brewer of the teams he’s worked with both at Abstract and in his experiences 
with startups. “People who really want to work with their counterparts. The 
designers are engineering-focused, the engineers are design-focused, and every- 
body’s product-focused.” This cross-functional and sometimes overlapping skill 
set is what Brewer seeks and what informs his hiring decisions. A word of cau- 
tion here, however: although multidisciplinary people who can jump between 
roles might be ideal for startups, these characteristics don’t always gel in larger or 
mature product organizations. We’ll dig into that subject in the chapters on 
emerging and enterprise organizations. 


It can also be tempting to try to find that perfect person who has deep experience 
and skill in all the areas you might need them to work on, but so-called unicorns 
like that are very rare and this risks dragging out your hiring process indefinitely. 
It is far more important to find someone with deep experience in an area where 
help is needed, and who brings the right attitude and aptitude to pick up in other 
areas as required. 


Aligning team members 


Not all product teams will be constructed from people with product backgrounds, 
and not all alignment is internal to the product team alone. “We are a super 
early-stage startup. Only a three-year-old business,” says Mark Coffey, Chief Rev- 
enue Officer at Boston-based startup Gameface Media. He describes his experi- 
ence with startup product teams: “We have a very, very small team. We’ve got a 
CTO, two developers, and then someone who is playing a product role, but not 
necessarily a person with a strong background in products.” For Coffey, his prior- 
ities for generating revenue have to be aligned with the product team’s work. “I 
love our current CTO right now because he gets that the reason for the product’s 
existence is not just to create a customer, but also to create revenue and a profit. 
Anytime I can sit with a product person who can see all the obvious agendas in 
the room, I’m happier.” Coffey feels that a good product leader will always under- 
stand that at some point the work will have to be monetized and the business 
made profitable. When Coffey is planning and interviewing for new product 
hires, he’s looking for product people who “are very, very good at joining the 
dots.” 


Finding the right people to connect the dots is about doing the work within the 
context of the business and market. That means being contextually aware and 
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sensitive. For example, one of the things that is perennially hard with the design 
of products is that everybody thinks they have a little bit of design capability— 
especially the CEO. A designer on a product team needs to allow for this, but 
should filter the inputs through the lens of the user experience. Coffey describes 
how these scenarios bring out the best “dot connecting” in product people: 
“What is critical in a product person is to be able to take all the noise and conver- 
sation in a room and turn it into something they can execute on. Then bring it 
back to the team in a way that everyone feels like their input was heard, while 
staying focused on the consumer experience.” Managing expectations, creating 
solutions, and balancing inputs with market needs is just a day in the life of a 
product creator. It’s no easy task but possible to do with practice. 


Here are some suggestions for filtering, collecting, and communicating inputs. 
Asking these questions in meetings and after meetings will help filter the signal 
from the noise and allow the product leader to focus their communication and 
action: 


1. It is clear what the real struggle is? In other words, can you see beyond the 
noise and identify the real problem or pain? 


2. Can you discern whether that pain is something aligned with the vision 
and roadmap of the product or company? Does it need to be solved? 


3. Does the company need to solve this problem to achieve its goals? How 
urgent is this to delivering value to the customer? 


4. If urgent, then does the company have the resources to solve this problem 
right now? Or should we postpone it until later? 


5. If the resources are available, does this reinforce the value of the product? 
Or does this reduce the value? 


6. If it reinforces value, is that value easy to describe and communicate to the 
customer and product team? 


7. If not, why is it hard to describe? Is it just complicated or is it not aligned 
with the vision, brand, or roadmap? 


THE STARTUP ORGANIZATION | 139 


Aligning leadership style with team style 


Aligning personality types with organizational personalities can be difficult. As 
with any successful business, it’s best to connect the personal goals of the team 
to those of the organization. “I always try to think about teams in terms of what 
their ambitions are. You have to create an environment where they have some- 
thing to look forward to,” says Placester’s Fred Townes. 


Making sure the team personalities match the organization personalities before 
you even make the commitment to hire them solves a fundamental problem for 
Townes: “To put it simply, it creates an opportunity for them to be self-motivated, 
and for them to stretch and want to grow.” Townes admits that it’s easy to say 
that, but much harder to implement this strategy. To be successful at this align- 
ment of business and human personalities, you have to be able to demonstrate 
the steps to achieving their personal goals within the organization. 


For the product leader, it often boils down to belief systems. At Placester, con- 
cepts like servant leadership,” making data-driven decisions, and wanting to test 
hypotheses all align strongly with their founder’s philosophy of how good prod- 
uct is created. These ideas are at the core of their hiring conversations. 


“I’m looking for people who are willing to learn and discovering what they natu- 
rally believe,” says Townes. “When they demonstrate that they do [learn], they 
tend to be successful, if not wildly successful at it, because they get to take their 
intuition and use that to form a hypothesis.” Aligning the product leader’s behav- 
iors and philosophies with an environment that allows them to amplify those 
characteristics is the goal for Townes. The product leader gets provided with a 
safe place to be their best self. “They get to do experiments, which is a safe way to 
validate things. The results allow them to develop, and their intuition gets 
enhanced. At the same time, they're progressing and moving forward toward cre- 
ating some value for the business.” The lesson here is that when you hire people 
that share the same product philosophies as the company, there is less friction 





7 The phrase servant leadership was coined by Robert K. Greenleaf in “The Servant as Leader,” an essay 
that he first published in 1970. In that essay, Greenleaf said, “The servant-leader is servant first. It begins 
with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire 
to lead. That person is sharply different from one who is leader first, perhaps because of the need to 
assuage an unusual power drive or to acquire material possessions. The leader-first and the servant-first 
are two extreme types. Between them there are shades and blends that are part of the infinite variety of 
human nature.” 
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and more value creation. Our caution here is that hiring people who are simply 
agreeing with you, whether you're right or wrong, is pointless. A mature product 
leader is committed to the customer-centric way of making product and should 
always hire for that alignment. 


Being user-centric 


Creating a product purely because you have a cool new technology is not a solu- 
tion. We’ve heard this described as an “elegant solution looking for a problem.” 
Who will be the humans that delight in exchanging time, money, or energy for 
your solution? Have you really listened to them? Have you immersed yourself in 
their world to truly understand their pain? 


There’s a demonstrable difference between people who have developed that user- 
centric muscle and those that haven’t. Practically, you can test this during hiring 
by asking prospects how they would solve problems. Each organization will have 
a different way to do this based on who is interviewing the candidate. The goal 
here is for the interviewer to see how the candidate works the problem as a prod- 
uct thinker. Do they start talking about technology solutions before they even 
consider the user’s experience? Do they reference subjective opinions instead of 
describing how they would establish objective research? Do they describe how 
they would be working as a team, or do they consider themselves to be individual 
contributors? The process and solutions they describe during the interview will 
indicate their future behaviors. Alignment between their responses and what 
you're trying to create in your organization is critical to a successful product orga- 
nization. 


“It’s definitely about finding people who are skilled at what they do but, by 
default, customer focused,” affirms Joshua Porter, cofounder of the product 
design firm Rocket Insights and former Director of UX at HubSpot. “I remem- 
ber talking about this a lot at HubSpot. We would interview candidates and 
always talked about people in terms of their default being customer focus. We 
would have them prototype something, or sketch out a flow, and would always be 
asking: are they talking in the voice of the customer?” 


This default position isn’t only in their approach to work. Product leaders will 
reveal this customer-centric default in their writing too. Leaders like Porter, who 
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coauthored 52 Weeks of UX with Josh Brewer,® says he finds clues for this position 
in new recruits for his product team in “whether they write in first person or 
third person. When we recruit that’s definitely a very key trait.” Porter observes 
that writing in the third person indicates a lack of ego on the part of the candi- 
date. This is essential for team alignment if you’re looking for the people who 
focus on creating a great product by doing well by the customer and not just serv- 
icing their egos or making a name for themselves. “You might say it’s a frame of 
mind,” Porter says. “It’s also the most important thing about building teams. 
Obviously, you need the right skill sets and you need a good balance between the 
skill sets and all that stuff, but I think the frame of mind is really a big part of a 
successful team.” 


According to experienced product leaders like Porter and Townes, it’s important 
to have the soft skills aligned first. Once the common ground is established, you 
can find ways for the new team member to have an immediate and positive 
impact. This requires aligning their hard skills with the job at hand so they can 
hit the ground running, and begin adding value to the process immediately, but 
also giving the individual an opportunity to create personal traction and some- 
thing to reference as they grow. Townes elaborates, “You can start looking at 
stretch opportunities either because they want to move on to another role or take 
another step, or because that’s just what the business needs and they’re the per- 
son closest to being able to meet that need.” A requirement for this strategy of 
producing good candidates is having a pipeline of talent to select from. Industry- 
specific hiring strategies and tactics are not the purview of this book, but product 
leaders need to hone their skills in this important area. Startup product leaders 
especially need to be mindful of their company’s growth and who their next hire 

might be. 


DEVELOPING TALENT 


For members to transition into different roles inside any organization, there 
needs to be a dialogue between the individual and the product leader. This is 
more important in an early-stage company where expectations are that a team 
will grow quickly and roles will switch more frequently than in a mature com- 
pany. That dialogue needs to be very intentional, since most employees of early- 





8 52 Weeks of UX 
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stage companies can’t imagine what life at the company will be like in a year or 
two from them joining. 


If there are gaps in the team, the leader needs to communicate either how exist- 
ing team members might fill them, or how outside talent could be recruited. This 
can’t be left to chance if the team is to feel aligned with the company vision and 
with their personal goals. Somewhat counterintuitively, it’s easier to see the gaps 
that need filling in larger teams. Highly specialized roles become immediately 
obvious in larger teams, whereas smaller teams with lots of overlapping roles 
might obscure the talent or skills gaps. “Basically, the larger the team, the easier 
it is to hire, because the gaps are very certain,” says Townes. 


Once that person is on the team, they’re going to evolve and grow. The challenge 
for the leader is to decide which growth path is going to be the best for each 
member of the team. Even though the leader is building a team, they also need to 
be consciously spending time developing each team member’s professional 
skills. This is a complicated task. As is the case with most of product leadership, 
it requires the leader to hold two contradictory ideas in their head at the same 
time. A great team is made up of great individuals. A great team is also made up 
of very diverse individuals. Protecting that individualism and diversity might 
sound contradictory to making a unified team, but it’s what works. What makes a 
team bond isn’t having a big homogeneous blob but rather keeping them aligned 
to a common goal. Preserving individual differences is possible when the team 
sees how they can work toward a common objective without having to give up 
their identities. 


The way to do this is to make sure the vision and values of the company are held 
high and communicated directly while giving each team member attention to 
growth their strengths. The message is, “Look, we’re all different, but we all 
share the same vision and values.” This preservation of diversity and unified 
effort can be seen in sports teams too, where lots of different roles and skill sets 
work toward a common goal. 


This brings us to the unique challenges of product leadership in emerging organ- 
izations, the topic of our next chapter. 


The Emerging 
Organization 
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The Biggest Challenges for Emerging Product Leaders 


A key challenge as a company grows from a nascent startup to an emerging orga- 
nization is to manage the growth of the team. This doesn’t only mean ensuring 
that the right people are coming on board, but also managing the transition from 
a small team—with little or no communication overhead—to a larger team that 
requires explicit, thoughtful communication and alignment with one another 
and with the product vision. As the team grows, the biggest challenge might be 
maintaining a focus on the user, as more layers inevitably get introduced 
between the product leader and the customer. 


Paul Adams, VP of Product for Intercom, agrees: “The biggest challenge by far 
has been communicating our philosophy and process to people as we’ve grown. 
Even our three core principles—to ‘think big, start small,’ ‘ship to learn,’ and 
‘design from first principles’—they’re kind of easy to understand at a basic level, 
but the nuances are huge. So our biggest challenge has been to translate our 
product management philosophy to all of the new people who join. Because all 
the people who join have to hit the ground running, and we’re all moving at such 
a huge, fast pace that there isn’t enough time to cover the basics.” 


This challenge is not restricted to management principles, but applies to leader- 
ship principles too. Growth affects almost all operational aspects of the business, 
but the core vision needs to remain consistent. 


Another challenge for leaders in growing companies is the shift from managing 
things to managing people. To put a finer point on this, leaders are moving from 
managing things to managing and leading people. Without doubt, this transition 
from manager to leader can be a deciding moment for a leader. Silicon Valley 
Product Group (SVPG) partner Chris Jones gives an example: “One of my first 
managers, Steve Roop, gave me one of the single most impactful bits of advice in 
my career. At the time, I was recognized as an effective individual contributor 
product manager, and was about to make the jump to hiring and managing my 
first direct report. Steve told me that there were two important things I needed to 
communicate to this person in the first week. Firstly, the new team member 
must understand that it is their job to know more than anyone in the company 
about their product area and its customers. Importantly, this person needed to 
know more about these things than I did, and Steve knew that I knew a lot. Sec- 
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ondly, the new team member should have a publicly visible ‘win’ sometime in 
the first 90 days from their start date.” 


As we've described before, the moment you realize that you don’t need to be the 
top technical contributor of your team can be both shocking and enlightening. 
It’s at that moment that you realize you are no longer a technician and that you 
are on the path to true leadership. “This advice was deceptively simple, but it 
worked on me at a very deep level,” continues Jones. “It has guided me through 
onboarding new product managers and transitioning new managers of product 
managers ever since.” 


As Jones and others have discovered, transitioning from being technically 
focused individual contributors to people-focused leaders can be a slightly trau- 
matic experience, both for the new recruit and for the person managing that per- 
son. A lot of our identity is tied to our work and our skill sets. We work for years, 
if not decades, honing those skills, so when we’re moved to a position that no 
longer pays these skills much attention, it can be jarring. Suddenly being thrust 
into a position that requires a new set of skills can push us out of our comfort 
zone and make us feel somewhat vulnerable. For leaders who are overseeing 
these transitions or actively advocating for them, it’s important to realize this can 
be a tough time for the team. Being sensitive to these transitions, and coaching 
the teams through them, makes a big difference to the outcomes. 


MAINTAINING A USER FOCUS 


If you’re the Chief Product Officer, a VP of Product, or a CTO, it’s a huge risk for 
you to make the user experience, product management, and technology decisions 
solely by yourself. Who’s to say that you alone know what’s best for the product 
and how your decisions are going to affect tens of thousands—or even millions— 
of users? For instance, we recently observed product leaders in an emerging 
healthcare-related organization reviewing design comps just before shipping. In 
this scenario, the design decisions are being made in isolation, without any feed- 
back from the end users. That’s a huge risk for an organization to take. They are 
assuming that they have total understanding of what millions of healthcare pro- 
fessionals or patients would prefer to see on the screens of their digital product. 


If you have disagreement within the team, you have a bottleneck to shipping. “As 
a product manager you have to prove the case for why the company should make 
a certain decision or not,” says Jacquelle Amankonah, YouTube’s Global Pro- 
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gram Manager. “If you don’t back up your idea with facts and data, or only rely 
on intuition, a lot of people won’t take your argument seriously.” Our product 
leaders’ experience suggests putting the user at the center of this decision and 
have the user break the tie for you. Of course it’s never that simple. The chal- 


lenge is balancing inside knowledge of what the business needs with customer 
feedback and data. 


“How do we continue to have high-quality service and continue to push the road- 
map forward quickly? I would say that is the biggest challenge,” says Bryan Dunn 
of Localytics. So how do product leaders with a fast-growing or large user base 
solve this problem? The solution appears to be rooted in two areas. First, the 
foundation of every successful product business is that it is a human-centered 
organization. Secondly, as the disciplines of the organization grow, the pillars of 
human-centered design and product development are consistently held up as 
sacred. This requires leaders to evangelize and lobby for the interests of the cus- 
tomer. 


Founders are exposed to this early on and can get beaten down by it pretty 
quickly. It’s easy for early-stage leaders to believe they have all the answers. 
When customer feedback comes in that contradicts the leader’s assumptions of 
how the product is supposed to work, it can be distressing. Healthy leaders 
undergo a transition, and learn to be a servant leader—that is, they learn to serve 
the customer’s needs and not just their own ideas. The opposite, and unhealthy 
behavior, is to ignore customer feedback or research. This latter approach has 
been more popular in the last decade, and leaders that adopt it are often heard 
paraphrasing Steve Jobs, who said, “People don’t know what they want until you 
show it to them.” This idea, from a 1997 Jobs interview with Business Week, has 
become a convenient excuse for product leaders to eschew market research and 
customer feedback. What’s overlooked when they repeat this story is the fact that 
by then, Jobs was already several decades into building consumer products and 
had amassed years of feedback from which he could make product predictions. 
Apple was also a billion-dollar global brand by then, giving Jobs an almost unique 
ability to launch products with unequalled marketing strength. Almost no other 
company in the modern era, and certainly no other consumer product leader, has 
achieved this type of effectiveness. Apple wasn’t exempt from product failure 
either, and it took decades to achieve its success. Trying to use Jobs’s words to 
describe any other emerging product development is naive. 
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CHECKING THE EGO 


Listening to your user is a far better approach for modern product leaders. It 
immediately reduces risk. When they start to interact with your product, users 
show you things that you might never have imagined or protected against. Some 
leaders may feel that exposing their new creation to users too early will reduce 
the purity of their manifestation. This is the ego talking. Being open to this feed- 
back isn’t a blow to your original ideas; it’s the best short- and long-term decision 
you can make. The product might be a manifestation of your creative process, 
but if you and the team have done your qualitative homework, there’s nothing to 
fear—you’ve set your product up for success. If you hide from the truth that user 
research reveals, you’re setting yourself up for an uphill battle. Homework, when 
executed correctly, means going beyond talking to users to include research into 
the competitive and market landscapes and the technical feasibility of the solu- 
tion. 


As Reid Hoffman, the founder of LinkedIn, puts it: “If you are not embarrassed 
by the first version of your product, you’ve launched too late.” 


As the company moves through each stage of its growth, the founders’ egos may 
undergo some friction. Once a startup prepares to ship its first product, things 
become more important to a founder or to the business. At this and other transi- 
tions, it can be easy to lose sight of the product vision and the desired experience. 
Egos tend to make even the smartest people retreat to familiar ideas and shut 
down external inputs. Doing this means running the risk of losing perspective 
and sight of what the users really want. 


During these transitions some leaders might ignore the big picture and distract 
themselves with details. It’s not uncommon to see product leaders focus their 
attention exclusively on the numbers. They start looking at coin operation, reve- 
nue, LTV (lifetime value) to CAC (customer acquisition costs), and length of stay. 
It’s all unit economics at that point, but again, the danger is that they can lose 
sight of what the user wants and values. Stay centered on the user—their actual 
likelihood to buy, and all the factors around retaining really great customers— 
and this problem solves itself. Companies that are motivated to grow in size and 
scale generally don’t have founders that are user-centered or empathetic at their 
core. “I think it’s important to care about what you’re building and who it’s for— 
taking more than just a shallow approach to understanding the user’s perspec- 
tive,” says Marco Marandiz, who has worked at CapitalOne, has built products 
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like HoverCards and Instant Logo Search, and is currently Product Manager at 
HomeAway. Marandiz thinks that having an understanding of behavior is not 
enough; he believes that it’s the foundation, but that looking more closely at how 
people interact with the product solves the problem more effectively. “I think this 
whole idea of empathy needs to be present from the top—in designing the expe- 
rience, through product management, and down to the developers,” says Maran- 
diz. “Product management should always be asking: What is this product we’re 
making? How is it actually valuable?” Marandiz says the feedback needs to come 
from the people in the trenches of product creation and that the organization 
benefits from these voices. If an engineer doesn’t believe that what they’re build- 
ing is actually good for the user, then that opinion should matter. Investigate that 
opinion. Understand why you’re creating a feature or optimizing one. “If you 
know the goal is to make somebody spend to or 15 more minutes on your prod- 
uct—even though it won’t actually add value to their life—that needs to be con- 
sidered all the way through [the organization].” 


THE JOURNEY FROM TECHNICAL MASTER TO PEOPLE LEADER 


Product company founders and leaders come from a wide array of backgrounds. 
There are sales and marketing CEOs, engineering-focused CEOs, operationally 
driven CEOs, and design-minded founders, to name just a few. Right now, prod- 
uct leadership in the digital space is relatively new, and there are not too many 
founders or CEOs that come from a purely product background. This might 
seem unusual, but it’s merely a function of time: not enough has passed for 
senior leaders to have amassed exclusively product-based experience. 


Sometimes the transition from technical leadership to product leadership can be 
bumpy, and dramatic role changes are not uncommon. “They talked to one of the 
senior developers, plucked him out, made him a senior product manager, and 
plucked me out of customer support and made me junior product manager,” 
remembers Janna Bastow, cofounder of ProdPad and cofounder of Mind the 
Product. “[They] put the two of us together, and that was the first product team 
this company had seen. This was a 10-year-old, IPO’d tech company with more 
than 300 people who had never had an actual product person.” Bastow’s experi- 
ence might sound familiar. It’s not uncommon for product leaders to be in tech- 
nical positions one day and leadership positions the next. “It was quite the task to 
take over. We started off by googling stuff like, ‘what is a product manager?’ and 
‘how do I do a product spec or a roadmap?” or things like that.” 
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These sudden transitions still happen in high-growth companies today. But this 
is changing. Our perspectives are almost entirely informed by the pace of tech- 
nology and innovation. We are still in the honeymoon phase of technological evo- 
lution, and things will probably remain this way for some time. Our prediction is, 
if you are a product leader, then your technical strategy is also likely to be your 
corporate strategy. Whether you like it or not, it is the way of the world. That will 
slowly change and shift toward a more human-centric set of strategies, but for 
now the challenge is overcoming the desire to frame all things by the technical 
conversation. 


CONNECTING THE DOTS 


The common threads that tie an organization together through each stage, 
whether it’s an emerging startup or an enterprise, are the following: 


The technology stack 
+ The experience being built 
e The affordances that are put on the page to accentuate that experience 


+ How the user interacts with those things 


At each of these points, you need to consider where you’re meeting the user. 
Knowing what happens when each element of your business crosses paths with 
the user is your job as product leader. No value can be created in a commercial 
product venture without a customer. Connecting the dots between tech, experi- 
ence, affordances, and interaction through the lens of the user or customer is a 
challenge a product leader must embrace. The work on these tasks is too often 
divided across groups or teams. That’s a mistake. Understanding how the tech, 
experience, affordances, and interactions work together should be the objective, 
and building teams and communication flow to connect those dots goes a long 
way toward reaching it. 


Technology trends—not only the stack of technology, but the devices that deliver 
the experiences—are evolving faster than the product leader can accommodate. 
Whether it’s a wearable device, an IoT device, a native iOS, Android, or a desktop 
or web app, there will always be more vectors than a single company can address 
effectively. Just think about all the things that you have to keep track of, depend- 
ing on your corporate strategy and where you’re going to market. To avoid having 
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the technology conversation completely overwhelm every decision, the product 
leader needs to seriously consider centering the company on a foundation prod- 
uct. When the company has a core foundation, it becomes the single source of 
truth. A core product or platform provides a lens through which other business 
and operational decisions can be filtered. It becomes infinitely easier to project 
out from the core and inform marketing and sales, customer service and support, 
and customer success. 


SUPPORTING TRANSITIONING LEADERS 


For many high-growth companies, one of the greater challenges will be providing 
for product leadership transition paths. Early-stage companies might still have 
one or more founders involved in the day-to-day running of the product, but 
emerging or fast-growth businesses will want to outgrow this setup. They will 
need to hire product managers to lift the operational burdens off the senior prod- 
uct leaders. Naturally this causes a new set of problems. The first challenge is to 
balance the pace of growth and the interplay with a leader trying to break through 
to the next growth phase. In many cases, product managers who want to become 
product leaders find this a really tough phase. Up until then the product leader 
has been a practitioner. The practitioner is primarily a role characterized by hard 
skills. By contrast, a leadership role has a much higher degree of interdependent 
soft skills. It’s not uncommon to see a product manager in the middle of this 
transition going back to place their hands on the practitioner’s wheel. It’s their 
comfort zone. It’s what they know. Hard skills mattered for so long that they 
understandably started convincing themselves they didn’t need to focus on soft 
skills. “We’ve been around for close to eight years now,” says Bryan Dunn of 
Localytics. “We have a lot of product. When you’re an early-stage startup, you 
need to just keep shipping product in order to hook a big customer so you can 
continue to pay everybody’s paycheck and you’re not running out of runway. 
Were at the point now where we have great product/market fit and need to be 
way more thoughtful about what we ship, and more importantly what we don’t 
ship.” This last point is the aha! moment for companies in transition. At first you 
can’t ship enough, but at some point you’ve got the reverse problem. “Everything 
you ship requires a certain amount of maintenance, service, and support, which 
causes you to get slower over time,” says Dunn of this challenge of product debt. 


As the leader of the product organization, it is essential that you don’t ignore this 
or assume the transitioning leader can manage on their own. You must take 
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notice and work through the transition for the team’s and individual’s sake. We 
have seen time and time again that when a product manager tries to make the 
leap, one of two scenarios occurs. In the first scenario, they make the leap, and 
the soft skills can’t make the shift. In the second scenario, they make the leap to 
leadership, but the team leader above them doesn’t create space for the individual 
to calibrate into the role. Both these scenarios have the same outcome: a failure 
to add value on the part of the transitioning leader and disappointment for all 
sides. 


PREVENTING COMMUNICATION BREAKDOWN 


As we've said before, the way teams communicate is a major make-it-or-break-it 
point. All really great products live or die by communication. This goes for com- 
munication within the team and inside the product, and only becomes more 
important as the team and organization grow. Here are four simple tips that 
might help product leaders improve their communication skills: 


e Acknowledge personal bias. As Automattic’s John Maeda reminds us: 
“Don’t forget that people make the stuff. Relations make the bigger stuff. 
Get the relations and people part right, first. The rest will follow.” In the 
user experience world, we are used to considering the needs of the user (or 
at least we should be) and must apply this concept to how we communi- 
cate with others. When product leaders are trying to communicate some- 
thing, they need to think about how people experience them as a leader. 
It’s not just about what they say, but also about how it will be perceived or 
understood. Leaders can often fall into the trap of assuming that whatever 
they say will be understood exactly as they intended. To demonstrate this, 
we'd like you to think back to yesterday, and any interactions you may have 
had with your peers, family, and friends. Take a moment and consider 
how they might have experienced you as a person and your communica- 
tion. Then go ask them how they actually experienced you in that moment. 
Don’t explain, don’t defend; just sit there and listen. We bet your intent 
and their experience don’t line up. 


+ Practice active listening skills. In order for really effective communication 
to take place in any situation, people need to have a desire to listen to you 
and what you have to say. A good exercise in being present is to listen 
intently to the person communicating with you, and then play back to 
them what you think you heard. This conveys that you have actually been 
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listening and opens up a magical place where people want to co-create 
something with you and are prepared to listen. 


e Take the information from whence it comes. Now combine the two previ- 
ous points—bias and listening—and consider the other side. Because com- 
munication is two-sided, where delivery is one side of this equation and 
receiving the other, some people have a listening problem. Delivering 
communication to these people is inherently problematic for leaders. 
From high-level concept strategies to daily task delegation, whatever you 
are trying to get across is going to be filtered by the receiving party. When 
people listen to you they subconsciously place you into what we call a “lis- 
tening bucket.” For example, let’s say you are trying to communicate a new 
experience release to the sales team responsible for selling it. When the 
sales people listen to you speak, in their mind they think of you as the 
product leader. This is their confirmation bias. They place the conversation 
in the “product leader” listening bucket. This means when the leader is 
speaking in the context of sales or something sales related, people dimin- 
ish the emphasis of what you are trying to say because you are not the 
sales leader. This can be an opportunity for the smart leader. If you spend 
time trying to relate to or seeking to understand their context before you 
start communicating what you want them to learn, they will feel some- 
thing different, something more resonant with their interests and ulti- 
mately more impactful. You are no longer in the “product leader” bucket 
because they feel like you understand their world. We first need to listen, 
then use language backed up by action in a way that connects with them, 
not to them. 


e Remove distractions. Finally, there are also more distractions in the work- 
place and at home than ever before (notifications from devices seem to be 
deliberately designed to interrupt conversations), and this can contribute to 
communication breaking down or people having trouble transferring 
ideas. We encourage you to ban nonessential devices in meetings. 


Here is the challenge we pose to you. In order for you to listen to the user and be 
the best leader possible, you need to master relating, co-creating, and delivering 
with your team. It’s essential that the product leader develops these skills. If you 
can’t do this well with your own team, then you are unlikely to be able to do it 
with customers and potential customers. Fine-tuning your listening and co- 
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creative skills doesn’t just make you a good product leader; it makes you a good 
product manager. 


Practical Advice for Transitioning Leaders 


Emerging companies have a very different flavor than startups. They are no 
longer dealing with the chaotic environment that’s so common to early-stage 
organizations, but it’s very possible that the hangover of being a startup hasn’t 
quite worn off. Habits, behaviors, routines, and responses that worked in the 
startup situation start to develop cracks when the company and the product team 
begin to scale. These behaviors might have worked to get the company off the 
ground, but there’s a real threat that they could now start to undermine the suc- 
cess that’s been achieved. The emerging company might still have the spirit of an 
early-stage venture, but the systems or processes that worked at the beginning 
probably won’t translate. This means leadership too. In extreme cases, that might 
mean a new leadership team, but for most organizations, this transition will be 
mostly about putting the right people in the right positions to ensure smooth 
growth and continuity. Knowing what to do is a function of the company culture 
and the constraints they face. 


To illustrate the differences between leadership at a startup and an emerging 
company, let’s imagine a common scenario. 


A high-growth company has reached its escape velocity and is now delivering 
product to an ever-expanding audience of users. The company has a lot of good 
new product ideas, and its primary product has started to establish itself. Its 
model is proven, and it is able to invest time, money, and energy into thinking 
about other product lines or features for its current product. In investment speak, 
it’s got traction. It’s also got real customers. The company no longer relies on 
stand-ins for customers like untested personas or market data. It is getting real 
feedback from real people. However, new ideas for product and features are still 
primarily coming from a small group of senior members of the company. That’s 
how it’s always been, so only a few people on the team notice that customer input 
is getting diluted by senior management’s ideas. For product leaders at this 
emerging company, the challenge is how to ensure a smooth transition from 
internally focused thought processes to a holistic consideration of all inputs. The 
question now becomes, how do you put a lens on the right ideas and the right 
feedback so that they get the attention they deserve? 
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Further complicating this transition for product managers are the day-to-day 
incremental fixes and improvements that need to be sustained and maintained. 
The answer to a successful move from startup leadership to growth-stage leader- 
ship is to return to the core. The leaders must go back to the core vision of the 
business and make sure it still makes sense and is still understood. If this 
sounds like a step backward, remember that leadership is always about vision, 
regardless of stage. People follow leaders that can clearly articulate the vision and 
future of the company. Technical and operational excellence might be a way for 
leaders to gain credibility, but nobody follows a leader entirely because of the 
craftsmanship. 


Product leaders need to ask themselves if they understand the vision clearly 
enough to communicate confidently to their team. Once you have an answer to 
that question, you need to be able to articulate it so that the team also under- 
stands and believes in that vision. If that all checks out, then you need to estab- 
lish a strategy behind that vision—a way to take the big-picture future and turn it 
into a path that will guide the team to that outcome. Put another way, the vision 
is aspirational and the strategy is execution. Senior product leaders, along with 
individual contributors, need to understand the difference between those two 
things. Vision and strategy are often lumped into a single bucket. This is a mis- 
take. They are very different things. 


EXECUTION INFORMS VISION 


The difference between vision and strategy is in how the value of ideas flows 
inside the organization. In healthy organizations, leaders, including product lead- 
ers, come up with the high-level vision for the organization. Then the execution 
of that vision happens at the individual practitioner level. Here’s the rub: just 
because the leaders are developing the vision doesn’t mean the value begins and 
ends with them. In order for the organization to remain focused and aligned, the 
value of ideas needs to flow up from the execution level back to the vision level. 
In practical terms, this means that practitioners need to be connecting their work 
to the vision, and leaders need to be willing to adjust the vision to accommodate 
the incoming insights from practitioners and customers. Once real customer 
data is available, the leaders have to be open to that vision being adjusted and 
accept that the strategy might change completely because of it. 


Let’s look at an actual example of how feedback from the trenches affects the 
vision and strategy. At Pluralsight the teams were working on a concept called 
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learning paths. Company founder Aaron Skonnard had a vision that their custom- 
ers, which they call learners, would benefit from a new way of using the web 
application. His vision was that from inside the web app they could elevate the 
learner’s experience from just learning specific skills to participating in a learn- 
ing path. These learning paths were like career paths. This insight came from 
observing how learners’ journeys correlated with topics popular on the compa- 
ny’s blog. There were over a hundred learning paths that had consistently been 
bubbling up from Pluralsight’s work during the previous five years, all highly 
trafficked areas on the company blog, so the team at Pluralsight knew they were 
popular and established. Skonnard felt strongly that because these learning paths 
were so popular, it pointed the way to a new vision—they needed to have learn- 
ing paths inside the web app. To test this vision, the product team designed a 
wireframe of the new version of the app as envisioned by Skonnard. 


But when the team went out and began talking to customers, they quickly discov- 
ered that learning paths were not resonating with them. Despite the fact that 
there was a lot of traffic from the website on those paths, the actual time that peo- 
ple lived inside these activities was very short. What Pluralsight’s product team 
discovered in this research was that the new vision didn’t mesh with the reality. 
They discovered that their primary customer, very seasoned developers with 7-15 
years of experience, wanted to scale up their skills but not on a predetermined 
career path. Instead they wanted to scale up skills in a specific technology. They 
didn’t want to become a frontend engineer; they wanted to learn specific technol- 
ogy skills like Angular, and then they wanted to scale up in Angular 2. That’s the 
moment where a vision was informed by the execution of a prototype and cus- 
tomer feedback about that prototype. All of a sudden, the vision needed to adapt. 


This example isn’t simply about a vision that didn’t work, but rather about what 
you can discover by allowing real-world testing to inform your vision. When the 
product people went out to test the execution of that idea, they discovered that 
instead of launching learning paths, they should be launching skill paths. So 
that’s exactly what they did. They learned in the marketplace, and it reshaped the 
vision. That insight changed the company’s product strategy and the product 
team was able to launch something that users were surprised and delighted by. 


At the same time, you have to keep your product vision in mind and not let your- 
self get sidetracked by all these new inputs. “People are always going to ask you 
to do more. If you follow them blindly, you can end up being in a different mar- 
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ket. Your product can have more features and a bigger footprint and more com- 
plexity than it originally had—and lose the focus that made it so valuable in the 
first place,” says Basecamp product manager Ryan Singer. 


Building Teams 


As we've already discussed, there’s no ideal way to build a team. Context is every- 
thing when structuring and hiring for a team. The lens that successful product 
managers put on this problem is the culture of the business, which, assuming 
it’s reasonably healthy, informs how the teams will be structured. Finding align- 
ment with the cultural context seems to be the first step in either building teams 
from scratch or restructuring them for optimization. “I think the most important 
thing with product managers is to think about who your people are—who is your 
tribe?” says Tim Buntel of XebiaLabs. “A product manager is going to be the 
voice of the customer. It’s a kind of cliché now in product management, but 
make sure that you like the people you work with.” Buntel knows that a product 
leader represents both the external customer and the internal customer. “You’re 
going to be their advocate, so you want to be able to walk a mile in their shoes 
and be the person who believes in them.” 


In emerging companies there will be an existing team in place, so the primary 
challenge for a product leader will be ensuring that team is aligned with the goals 
and culture of the bigger organization. Product teams are often focused on the 
day-to-day operations and might not see the bigger picture as often as leaders 
would like. “We need to work on helping them see longer-term priorities,” says 

Matt Asay, VP of Mobile at Adobe Marketing Cloud. “Sometimes the near term 
gets all the attention. I’ve helped [my team] get resourcing and help so they can 
see further out.” Asay believes that when product leaders help lift the team’s eyes 
a bit and see the longer-term horizon, then everybody wins. “My job is to be the 
glue,” says Asay. 


Team structure doesn’t have to be unique and original to each company. Borrow- 
ing from successful models that look similar to your organization can be a short- 
hand to your own team structures. When high-growth companies need solutions 
like how to structure their teams, they don’t always have the luxury of experi- 
menting with unique models and structures. “Organizationally, the product org 
includes product management, user experience, data science, product strategy, 
and product marketing,” explains Bryan Dunn of Localytics. “Then we have a 
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marketing department that’s separate that handles the standard marketing.” 
Dunn describes how the team at Localytics copied Spotify’s squad model to fast- 
track the structural model. “We have five crews that are all mostly full-stack. 
When I say ‘full-stack,’ they not only have the engineering competency across 
each stack, but they have a product manager, they have a crew lead (which is the 
technical lead), engineers, and some of the crews have a user experience designer 
if they’re developing on the frontend.” The core teams also benefit from floating 
experts that provide specific technical expertise to all the teams. Think of them as 
a team for the team. “Then we have our data science team,” continues Dunn. 
“They operate a lot like the user experience team where they’re a service that 
spreads across the crews, so there might be opportunities for a particular crew to 
work on some machine learning algorithms to improve part of the product. The 
data science team will work with them through creating those algorithms, and 
then move on to a different crew. They float based on need across the crews.” 


“It was definitely a challenge and I had to give it a lot of thought,” recounts David 
Katz, VP of the User Experience Practice at Virtusa Polaris, a global provider of 
financial technology products. Katz was hired to help Virtusa Polaris adjust to the 
increasing demand for user-centered design and development. “Being such a dis- 
tributed organization, we have people all over the world,” Katz says. “I wanted to 
do things in a slightly different way.” Katz approached the problem of building a 
product delivery group from a team-based point of view. “My goal was, rather 
than having a collection of people scattered all around the world, to build a cou- 
ple of studios where we have some depth and create some community around 
the practice.” Katz says that this is an ongoing process. No team is ever com- 
pletely static, especially with a company as large as Virtusa Polaris. Tactically Katz 
has established studios in the Boston area, another group of people in the New 
York area, and then a few remote workers. By building this capability around 
Boston and New York, the company is able to maintain a critical mass of capabil- 
ity and a sense of community. This might be challenging for some companies 
that have predominantly remote teams, and Katz’s solution isn’t a solution for all 
emerging businesses, but the point is that each company must find the right 
setup for their business. “We’re in the process of building a studio space in New 
York,” says Katz. “It’s important that we’ll have everybody under one roof. When 
people aren’t out at the client site, they'll have a really nice place to work and col- 
laborate with one another. That’s directionally where we’re headed.” 
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GETTING THE RIGHT PEOPLE ON THE TEAM 


Beyond location, how do you identify the people on the team? Once you’ve estab- 
lished your company’s preference for location, or the lack thereof, and the struc- 
ture, then you’ve got to find the human beings for that environment. How do you 
do that? “We’ve worked with a couple of recruiters that I had worked with over 
the years to help me find great people,” explains Katz. Having decided on a 
recruitment strategy, Katz was able to implement his plan in stages. The first 
stage was to create the core of the team. “We started building a nucleus of two or 
three people and radiated out from there,” explains Katz. “We’ve deliberately 
built the team slowly to maintain quality. I’ve been very conscious to not lower 
the bar.” Like other successful product leaders, Katz holds the quality of his peo- 
ple above all else. For fast-growing companies, this is extraordinarily difficult. 
There is always pressure on the product team to provide resources as they are 
needed. “That’s often a little bit of a challenge because we have an 18,000-person 
organization,” Katz continues. “As you can imagine, there are a lot of projects 
that have had latent needs for UX and product capabilities, so there’s this contin- 
ual pressure to add additional people to meet some of that demand.” The product 
leader needs to balance the needs of the organization with the need to maintain 
high standards in new hires. 


“I think there are a couple of things that we do as part of our recruiting and inter- 
view process,” says Katz. “One of the things that I find challenging is evaluating 
portfolios. Everybody has a portfolio, and lots of people’s portfolios have great 
stuff in them, but one of the things that’s really tough is to identify what that per- 
son actually did, and how did they contribute to the items they’re displaying in 
their portfolio?” Katz is describing the familiar challenge of evaluating work dur- 
ing one-on-ones with potential employees. As much as product leaders might be 
tempted to do what the rest of the organization is doing and go through some 
kind of standardized onboarding process, there is the threat that the bar might be 
lowered. The key is to try to separate the work that person has done from the 
overall output of the team they were part of. “Typically, people work on teams, so 
it’s often hard to isolate what contributions a given person made. One of the 
things that we’ve done to get around that challenge is to create a design exercise 
that we have everybody in the practice complete as part of the interview process.” 


Katz asks prospective employees to do these design exercises after their first- 
round discussion and once mutual interest has been established. “It’s a pretty 
straightforward exercise in that it’s really an ecommerce checkout experience—a 
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mobile ecommerce checkout experience, I should say.” Katz’s team provides the 
candidate with a user story and then asks the candidate to create a design that 
satisfies the story. “We leave it, really, pretty open-ended, and we found that it’s 
really effective. For one, it’s a story that people can wrap their heads around 
pretty easily and doesn’t require a lot of domain knowledge. Everyone has experi- 
ence dealing with mobile checkouts these days. But there’s a bunch of subtleties 
to the exercise that either people pick up on or they don’t.” 


Because there’s no right or wrong way to answer these requests, Katz says these 
types of thinking exercises enable the team to see where their skills and interests 
lie, “whether it’s in interaction design or visual design or information architec- 
ture. And the overall presentation of things: How did they do it? Do they use a 
prototyping tool? Do they do static wireframes? Do they do really high-fidelity 
comps? Or do they do things that are more structural and skeletal, but show the 
flow?” The insights gained through this exercise provide answers that Katz would 
simply never get from just looking at a portfolio or speaking to a candidate. “I’ve 
seen some examples that are just amazing and really out of the box, and there 
have been other times where I had really high expectations and I was disappoin- 
ted,” Katz says. “It’s a great way of cutting through to what people can and can’t 
do, how they think, and where they choose to spend their time.” 
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Four hundred twenty-nine of the original Fortune 500 companies open in 1955 
are no longer in business today. In fact, since the 1950s, the average lifespan of 
an enterprise company in the S&P 500 index has decreased from over Go years 
to just 15. Markets are changing faster than ever, and an organization’s ability to 
move at the speed of the internet is the only way to survive. That’s easy to say, but 
for most big companies, it’s almost impossible to do. 


With the speed of change only on the rise, it puts more pressure than ever on an 
enterprise organization’s ability to innovate, build great products, and disrupt 
itself before a competitor does. At the same time, the traditional tools of market- 
ing to win market share are failing, as the cost of acquisition and customer 
expectations increase, while the cost of maintaining and upgrading legacy sys- 
tems hampers new development. 


All this pressure lands squarely at the door of the enterprise product leader. 


The Biggest Challenges for Enterprise Product Leaders 


Enterprises share many of the same challenges that startup and emerging com- 
panies face. However, one unique challenge for enterprises is that they must con- 
stantly battle the complacency of product organization, pursuing innovation 
when necessary. An appetite for change needs to be nurtured, especially when it 
comes to established products. 


AVOIDING COMPLACENCY AFTER SUCCESS 


“Success is the biggest inhibitor to future success,” says Barry O’Reilly, coauthor 
of Lean Enterprise: How High Performance Organizations Innovate at Scale. “When 
you're running multibillion-dollar companies successfully, all your numbers look 
good, your charts are heading up and to the right, and all the strategies you’ve 
deployed your whole career have led you here, to the success you currently have. 
So, why change?” 


It may seem counterintuitive to regard success as a risk, but it’s been shown time 
and again that enterprise companies can get complacent with their position, and 
while focused on incremental improvements, they lose sight of the bigger oppor- 
tunity and get overtaken by younger, hungrier competitors. 
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“It takes real courage,” continues Barry, “to recognize that you constantly need to 
challenge yourself—to see if what you’re doing is working. Should you be trying 
something else? Should you change?” 


STAYING DISCIPLINED AFTER SUCCESS 


“The hardest thing is that you have all the money in the world,” says Lisa Long, 
VP of Product for Telenor, a Norwegian telco with over 200 million customers in 
27 markets. “What are you going to spend it on? Unlike startup companies, 
where you're starving for resources and you have to be very sensible about what 
you spend cash on, in a large enterprise company you have a lot of resources. 
The problem is you have so many resources that it’s very tempting to carry on 
with projects that are not particularly successful because you think, ‘Maybe 
there’s just one more discovery we could make around the corner.’ It’s very hard 
to know when to stop putting resources towards something, because it’s not as 
life-or-death as it is in a startup company.” 


MAINTAINING FOCUS AS YOU SCALE 


Any good product leader will tell you that you can’t be everything to everyone. All 
companies go through this struggle. They need to stay focused on a specific mar- 
ket while still scaling their business. For the most part, this might be easier when 
companies are small. Early-stage companies tend to be more focused on a spe- 
cific problem, but this becomes harder as they grow. By the time they are enter- 
prise size, the pressures of growth and scale diffuse any hope of staying focused. 


As the product leader in an enterprise, you might find that the hardest part of 
your job is delivering value to existing customers while simultaneously growing 
existing or new markets. There is no silver bullet for overcoming this friction, but 
there are some patterns worth noting from successful product companies. 


The first consideration for the product leadership is to ensure the organization 
has at least one product that truly sets it apart. Assuming you have multiple prod- 
ucts, you'll want one that stands head and shoulders above the rest. It doesn’t 
always have to be the same product, but for enterprises this would be something 
game changing or market leading, and that could deliver value for an extended 
period of time. For a consumer-focused company like Apple, this would be the 
iPhone. For a B2B company like Intuit, this would be QuickBooks. For Google, 
it’s search underpinned by AdWords. This product is your flagship and will carry 
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the dual duties of delivering massive value to the customer and the business, 
while also acting as the tallest peak in your publicity engine. For those companies 
that have a suite of products but no clear big hit, we recommend you pick the 
product with the greatest potential and focus on making it the standout. 


Tightly connected to this is understanding which of your products is the most 
effective wedge device for introducing your value to the customer. In many cases 
this will be the same product that stands out above the others, but it may not be. 
Figuring out which product opens doors and builds relationships with your cus- 
tomer base means you'll have an entry point for the other products in your suite. 
If your standout product is the marketing engine, then this product will drive 
your sales. 


Finally, the product leadership needs to focus on the most interesting customer 
segment. Not all customers are created equal. Some are responsible for high rev- 
enue but don’t have a big market share. Other segments have powerful network- 
ing influence but may not generate significant bottom-line value. It’s essential 
that the leadership determines which of these customer segments are going to 
achieve which OKRs. Connecting the dots here means launching a highly 
focused marketing effort that aligns with product delivery goals. 


Previously of HSBC and currently Senior Product Owner, Digital Workplace and 
Collaboration at Sainsbury’s, Randy Silver expands on these ideas: “Things oper- 
ate on a different scale in enterprise. At smaller firms, I felt like a failure if I 
couldn’t show results in two or three months. At an enterprise, a global change 
can take two or three years. Add a few more months if you’re in a regulated envi- 
ronment. Trying to deal with things like cross-border data transfer, bringing on a 
new vendor, or even asking for feedback from staff in other countries can be 
really complex. And not just the legacy systems. Processes can be absolutely 
byzantine, and the organizational dynamics even more so. Companies of this 
size often grow by merger and acquisition, and inherit different systems and pro- 
cesses between business units or geographies. There are also often undocumen- 
ted checkpoints that you'll need to go through to get any existing systems or 
processes changed, above and beyond the known structures.” 


Barry O’Reilly adds, “Typically the factors constraining innovation are conflicting 
business goals, competing priorities, localized performance measures, and suc- 
cess criteria. While these have traditionally been the tools of management—to 
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control workforce behavior and output—in highly competitive and quickly evolv- 
ing business environments, they also have had the adverse effects of killing crea- 
tivity, responsiveness, and ingenuity.” 


“We have over 140 products in our portfolio,” shares Maria Giudice, VP of Expe- 
rience Design at Autodesk. “You can imagine that there is a lack of cohesion 
from one product experience to the other. That made sense many years ago, but 
now as we are moving from being very software focused to being very experience 
centered, cohesion is a requirement. You have to ask yourselves, are your cus- 
tomers getting consistent experiences, or are you shipping the seams of your 
organization to them?” 


DELIVERING A CUSTOMER-CENTERED GO-TO-MARKET STRATEGY 


We are going to make an assumption here, but in most cases if you are building 
for the enterprise or you are an enterprise organization, you are most likely a 
publicly traded organization. If this is the case, as a senior leader, the term “beat 
and raise”! should be front and center in many of the discussions you are having 
each week. A big tension for a senior leader in product management is the sales 
and marketing teams’ influence in the product’s go-to-market strategy. Does 
product marketing live in product or does it live in marketing? Who is the tip of 
the spear of the how, the what, and the when for product releases? Who decides 
what features need to be built? Many of these kinds of decisions in the past were 
often, if not always, revenue driven. 


This won’t come as a surprise, but many of the companies we interviewed have 
their enterprise product roadmaps dictated to them by the upper third of their 
revenue-generating customers. The reason most often cited for this is that an 
organization can hit its annual growth forecast for the “beat and raise” model. 
Predictability around these metrics drives shareholder growth and value for 
nearly all of these companies. Sprinkle in some employee restricted stock units 
(RSUs) or other forms of equity for senior leaders and individual contributors, 
and you have a tenuous environment. This situation can get nasty if it’s not 
aligned with delivering customer value. Having been in this situation, we empa- 





1 Many stocks that make the cut and find a place in the portfolio are companies that “beat and raise” when 
announcing their quarterly financial performance. It means the company beat earnings and/or revenue 
expectations as published by the equity analysts, and then raised its own forward guidance. 
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thize with you. We know that this can seem like a bow wave that is insurmounta- 
ble. However, the best product leaders in the world have the ability to get ahead 
of this pressure. They have the ability to foresee what is on the horizon before the 
go-to-market teams do. A secret weapon that the most successful product leaders 
deploy is discovery and human-centered research principles. Collecting insights 
and data well before the executive and market pressures start dictating changes is 
critical at large product organizations. Product leaders need this customer- 
generated information before an analyst on an earnings conference call asks the 
inevitable difficult questions. 


The old saying “data doesn’t lie” comes in handy when attending executive and 
market metric-related meetings. Armed with statistically significant and repeata- 
ble data that show overlapping themes gives the product leader a huge head start. 
Data that reinforces what the customer segments want—and is willing to pay for 
—shows a path for future releases and innovations. It points out the importance 
of building a sustainable experience rather than a features and benefit model. By 
doing the research, a product leader is able to tease apart the wants of the upper 
third and the “beat and raise” situations, while simultaneously solving for the val- 
uable user and buyer base problems. 


COMMUNICATING AND COLLABORATING EFFECTIVELY 


The other common thread with successful product leaders in enterprises is their 
communication skills—and not just with their teams and direct bosses but with 
sales and marketing as well. The best product leaders have a kinship with their 
counterparts in sales and marketing. In some cases, leaders told us that they 
share desks to ensure consistent collaboration on all projects. For communica- 
tion between these departments to be effective at scale, we recommend at least a 
weekly meeting. The sales and marketing groups should regularly be informed of 
all the appropriate discovery and delivery updates. Equally important is for the 
sales and marketing counterparts to be passing insights back from their depart- 
ments to product. After all, sales and marketing are at the frontline every day and 
have lots of customer feedback to share. 


AVOIDING SANITIZED DATA 


Barry O’Reilly outlines what he views as one of the biggest challenges in enter- 
prise environments: “So much of the information that gets to executives is sani- 
tized. For example, a product development team might be working on something 
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and they push a report through, but there’s something they’re a bit ashamed of— 
or it’s a vanity metric rather than actual metric that they want to talk about, some- 
thing that’s really a problem—and they hide it because they’re afraid how itll be 
treated. Or, they put something red in a project and it goes to a more senior per- 
son and they don’t want get into trouble, so they turn a red to an amber. Then a 
more senior person changes that amber to a green. Suddenly, you’ve got leader- 
ship of these large companies looking across a dashboard that’s all green, and 
they’re going to make strategic business decisions based on this information. In 
other words, they’re making decisions off incorrect information. So it shouldn’t 
be a surprise when the decisions they make are wrong. Then the results are 
wrong. Now you have this cycle of bad information running up and down the 
organization, and as a result, bad decisions being made up and down the organi- 
zation, which result in more bad decisions, because the cycle is actually toxic.” 


This is where a product leader’s ability to simply get up and walk around the 
office, or out of the building, to speak to their teams and their customers really 
helps. Because getting that raw information directly from the source ultimately 
ensures you make better decisions. 


“Probably the best example of this,” adds O’Reilly, “is Reed Hastings at Netflix. 
He has a standing 30-minute meeting with all the directors of the company every 
12 weeks. Every three months, he has a customer-testing session with everyone 
who runs or leads a major department in the business to understand what’s hap- 
pening, what’s working, and what’s not.” 


Building this sort of sensory network—inside and outside the organization—to 
funnel accurate, unsanitized information and feedback up to the right people so 
they can make better decisions is the hallmark of an exceptional product leader. 


MEASURING THE RIGHT THING 


As we outlined earlier in this book, building great products relies on measuring 
the success of those products and your team’s ability to move the needle on those 
metrics. Most enterprise organizations, however, are measuring the wrong 
things. 


YouTube’s Jacquelle Amankonah measures success in a few different ways. On 
the creator side, what’s very important to YouTube is their satisfaction. “We have 
something called CSAT, which is creator satisfaction. We aim to make that high 
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as possible. Creators are the lifeblood of the product. Without them we only have 
viewers and their satisfaction.” The CSAT score measures YouTube’s product 
success by scoring the ease with which a creator can build a community on You- 
Tube. 


“How much are we communicating to them in a way that is helpful to grow their 
business on the platform? Are we giving them the tools they need to proceed? 
Are we clearly articulating strategies that they can use in order to grow on You- 
Tube? Our services, our support, our partnerships, etc. That’s a big metric for us 
on the creator side.” Amankonah also uses a number of surveys that her team 
sends to creators at various frequencies and with various types of questions. “I'd 
say that is the biggest driver [of data] into that metric,” she says. “We also make 
sure that we cross-check that metric in conversations with creators, to uncover 
more about the why behind some of the things that they’re telling us. Trying to 
dig into any variances we see between different groups or different verticals. Per- 
haps a music creator feels differently than a gaming creator; why is that? We aim 
to survey our creators so we can hear in their words and their opinions how well 
we are hitting the mark with them as a platform.” 


During their first 25 years, Adobe measured just one thing as its key metric: how 
many software packages it sold. But this metric doesn’t tell you anything about 
adoption rates, usage, or customer satisfaction, nor does it incentivize developing 
a long-term relationship with customers. What it does incentivize is selling cus- 
tomers a new version as often as possible. When Adobe moved to the cloud 
model, it also fundamentally changed its success metrics to focus on subscrip- 
tions—signups and renewals—which is a very different relationship to have with 
your customers. This change led to the Marketing Cloud, a whole new business 
area for Adobe, because it directly aligned the product (online marketing tools) 
with the customers’ needs (acquiring and retaining customers). 


How do you determine which metrics and measurements are right for your orga- 
nization? Given that you need to pick your KPIs (key performance indicators), 
OKRs (objectives and key results), or whatever measurement framework you 
choose to determine success, how do you know what will give you the right feed- 
back? The initial problem for many product leaders is they have a massive reser- 
voir of data and insufficient methods for turning that data into insights. Leaders 
need a process for how to pick and choose which measurements to focus on and 
why those are meaningful. 
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Jonathan Gowins, a Product Manager at D+H, describes the company’s 
approach: “One KPI is revenue. That’s just a simple one. If we can’t sell it, can’t 
generate revenue, then it’s not performing. The other [metric] is NPS, net pro- 
moter score, which has swept basically all industries by storm. So we’re in touch 
with how well it’s performing with clients and what perception is. Also just the 
hard dollars behind it, because some of you can sell something and you can 
really adapt the pitch, or the premise, or the value prop. Then once something’s 
live, maybe it actually tanks and it’s problematic. NPS will come in and pick up 
that sentiment and share that with us and give us that feel for the product. We 
use both of those things.” 


D+H is a fintech product company with a focus on designing and developing 
B2B solutions for the banking and finance industries. Money is inherently emo- 
tional. Saving to buy a new house, purchasing a gift for a loved one, or figuring 
out how to pay for costly car repairs all spark emotional responses. In an age 
where we're instantly connected to people around the world, we expect the same 
level of access and control over our finances. Gowins and other product manag- 
ers like him are listening to diverse stakeholder groups and distilling those wants 
into products that work for real people and their assets. Gowins knows that even 
though his company produces a B2B product, the end user is a priority, and it 
puts an emphasis on measuring that with NPS scores. 


Whatever scoring and measuring system you opt for, remember that what you’re 
choosing to measure will get the attention of your team and company, so choose 
wisely. “As far as data goes, we work with our clients because they set the prece- 
dent for what they need,” says Gowins. “Ultimately we deliver the solutions that 
they need. If they buy it, that’s validation number one. If we get a strong NPS, 
that’s validation number two.” 


This underlines the importance of choosing balancing metrics—tracking both 
performance-oriented numbers like revenue, ARR, and CAC, and quality or cus- 
tomer satisfaction numbers, such as LTV and NPS. 


WORKING WITHIN THE COMPANY CULTURE 


“Some people can have an entire career—with many different job experiences— 
within one large firm,” says HSBC’s Randy Silver. “This creates a unique corpo- 
rate culture, which may be hugely resistant to change, but may also be the reason 
behind the company’s original success and why it hasn’t yet been disrupted. That 
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can simultaneously be a huge frustration and a massive opportunity. Even if you 
never learn to love the culture, you’ll need to develop an appreciation for it. 
Without that, you'll never be able to engage the lifers.” 


Of course not every enterprise organization has this scale and culture, but even if 
it doesn’t, an enterprise product leader must consider how their team fits into the 
overall structure and its culture, while focusing (even more than their counter- 
parts in smaller organizations) on communication. Their ability to influence, 
lead, and inspire both laterally and upward in the organization is more important 
in enterprise organizations that need to create the space for a customer-focused, 
iterative product-development function. 


Enterprise product leaders must also be mindful of their company’s org struc- 
ture, budgeting and control, and development process. “When you create an org 
chart, you are creating your product—the seams in the organization get reflected 
in the product; the depth of feature work gets reflected in resource allocation; the 
coordination across job functions gets reflected by the leaders you choose; and so 


on,” says Steven Sinofsky, former President of the Windows Division at 
Microsoft. 


So in order to effect change, a product leader needs to be able to present it in a 
way that the organization understands. “By linking innovation to a growth strat- 
egy, it ensures it is a targeted, strategic, and funded priority for the organization, 
and provides alignment between business strategy and execution through the 
action of delivery,” adds Barry O’Reilly. 


Enterprise Leadership 


Tackling organizational design—and the leadership styles that accompany it—to 
set teams up for success is one of the hardest parts of a product leader’s job. This 
process uncovers a lot of obstacles for many organizations. Before we dive in, we 
want to take a moment to recognize one of the biggest hurdles. Power struggle, 
or a need to feel in control of a domain that a leader is assigned to, is systemic in 
many organizations and will undermine teams all day long. But we are cautiously 
optimistic that times are changing. Senior leaders are becoming more people 
managers than hard-skill managers. It’s true our organizations are still a little 
hungover from our former command-and-control partying years, so we still have 
leaders who default to this behavior. This often shows up in older companies 
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with senior-level tenured employees who still have these habits programmed 
deep within their DNA. However, we are seeing positive signs that this trend is 
shifting. We see a deep desire in seasoned technology and product leaders in 
larger organizations for moving toward people and culture management. They 
are showing an interest in making sure their leaders have both the hard and soft 
skills necessary to make this the focus. 


COMMUNICATING WITH INTERNAL AND EXTERNAL CUSTOMERS 


As the organization grows, so does the opportunity for poor communication. If 
your team is bigger than 20 people, it’s easy to forget to check in on a team mem- 
ber, or to overlook informal customer meetings. A healthy way to think about 
communication is this: everyone is a customer. That means that both internal 
teams and external users are your customers. As product leader you will get a 
better perspective when you see the world through the lens of your customer. 
Treating your internal team like customers automatically puts you in the servant 
leader mentality. A servant leader focuses primarily on people’s growth and well- 
being. Traditional leadership generally involves someone at the top of the organi- 
zation or team accumulating and exercising power. In contrast, the servant leader 
shares power, puts the needs of others first, and helps people develop and per- 
form as highly as possible. 


The best product leaders make time for communication by building it into their 
calendars. Just like getting fit requires you to add your workout to your schedule 
before meeting the rest of the obligation, so too does good communication. “I’ve 
made it a practice of mine to spend time with my peers and colleagues to make 
sure we're all connected. The human element is essential,” confirms Matt Asay, 
VP of Mobile for Adobe Marketing Cloud. This applies to connecting with teams 
and with customers. In maturing companies it’s easy to turn to the reports or the 
data and conclude you’ve done your homework, but the real insights still happen 
with face-to-face communication. “It’s not possible to do it any other way,” says 
Matt Asay. “Data is essential, but people matter more. Each week I buy lunch for 
anyone doing anything with mobile, assuming they are in the Utah office.” 


This kind of regular contact with team members is key, but there are other 
actions you need to take in order to understand your customer needs as well. 
Zmags’ Cait Porte says that communication in an established company needs to 
happen in a variety of ways: “This is probably par for the course for product man- 
agement. In some capacities I’m doing usability and user experience testing with 
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my team. I’m working with our UX team right now to build out what those sce- 
narios are, and to make sure that we’re listening to that feedback. In other sce- 
narios, I’m understanding what our customers’ top priority issues are, whether 
as a company or specific to our products.” This combination of formal and infor- 
mal communication provides a good chunk of what Porte needs, but she prefers 
to use structured exercises to get specific insights. “We do something called the 
hundred-dollar question: How would you spend one hundred dollars in our plat- 
form if you only had one hundred dollars to spend? It’s a great prioritization 
exercise to do with customers.” These highly targeted or structured communica- 
tions are designed to extract specific data or insights from customers. 


As with most leadership positions, a product leader is a bottleneck for communi- 
cations and, subsequently, decision making. If the product leader isn’t getting 
the right information, they won't be able to make informed or timely decisions. 
Knowing which channels and exercises get the most relevant and important 
information is part of the job. Just being a catchall for all the inputs solves noth- 
ing. In fact, the scenario of having to filter all the information through the prod- 
uct manager or leader makes the bottleneck problem even more acute. The best 
product leaders are also masters at filtering good communication from mere dis- 
tractions. They are highly selective when it comes to communication inputs and 
sources. Without question, the best source is the customer. Direct contact with 
customers and users is by far the highest-value input. “I probably talk to custom- 
ers at least once a day in some capacity, and I really like that because it grounds 
you when you’re thinking more strategically as a business,” says Porte. “Hearing 
from the customers and understanding what their problems are is really critical 
for product managers, and I like to make sure that I’ve kept that consistent 
through every role that I’ve been in.” 


“When we’re building the product, we do a lot of user interviews before we start 
the design work,” says Joe Ranft, cofounder and Head of UX of Cinch Financial. 
“We conduct one- to two-hour interviews with users, and that helps us define 
what information people need.” Ranft explains how his team would develop 
insights by making communication with customers easier: “We have one prod- 
uct which asks people to snap and post a picture of a monthly bill, and we let 
them know if they should change it. That was how we realized people don’t just 
want to shop around, they want advice. What we learned translated into working 
on a brand new product. I like UserTesting.com, but I also like to be sitting next 
to the user to be able to ask them questions, which I find harder with some of the 
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online testing methods. I’m still a big fan of traditional user testing where you 
recruit users, bring them in, watch them use the product, and ask them ques- 
tions about what they’re thinking as they’re using it.” 


Ranft confirms what Porte and others told us: that face-to-face communication 
with customers is the preferred method of getting useful insights. “You see their 
faces,” says Ranft. “You can tell when they’re confused. You can see, especially 
now in testing phone design, or mobile designs, people try to tap on things that 
don’t work. I think you really have to watch. With online user testing, it’s harder 
to tell what their feelings are. That’s why the old-fashioned way works: bring 
them in.” 


Because so much of the product leader’s work is digesting information and using 
that information to make decisions, they also need to understand that they are 
essentially acting as a filter to the team. They must ensure that only the most 
important information and critical insights are available to their team members. 
Taking this a step further and determining how to share these insights with the 
team is also part of the product leader’s job. “I also work on analytics with our 
customers because one of the things that we’re looking to do is build out an ana- 
lytics dashboard,” says Porte. “We’re really interested in understanding how the 
customer is measuring success. What factors are important to their business? 
What do they want to see in our products?” 


PROMOTING COLLABORATION 


Great product management “is about change, and change demands leadership,” 
says Autodesk’s Maria Guidice. “Therefore, today’s product managers and 
designers must be leaders. Go from being producers of artifacts to champions of 
a connected society. The best ideas and solutions come from multidisciplinary 
teams where everyone feels like they contributed to the process. Everyone is crea- 
tive. Make everyone part of the creative process.” 


Treat your peers and coworkers as co-creators, and respect the fact that each per- 
son is able to bring something to the table based on their area of expertise and 
their own view of the world. Be mindful that diverse teams may share the same 
goals, but they speak different languages. More brains produces more ideas and 
better solutions. How do you build a strong internal community? 
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“People think that cross-functional only matters at a small product team level,” 
adds Barry O’Reilly, “and that’s incorrect. The highest-performing leadership 
teams, we’ve discovered, operate at a cross-functional level across an entire busi- 
ness. That’s the whole point of having people who lead departments. It’s just at a 
macro scale rather than a micro scale, relative to an individual product develop- 
ment team.” 


CHANGING THE CORPORATE CULTURE 


“To break the silos, we are identifying big problems to solve, and then we are 
handpicking people from different products to solve that problem together,” says 
Maria Giudice. “This breaks down the silos, but it also makes for a better product 
experience because their individual product biases get baked into the strategy. 
We are also creating practice taskforces. We have people who are passionate 
about research, people who are passionate about visual design, people who are 
passionate about information architecture, and they convene and they have their 
own charters. Their job is to elevate the practice throughout the organization so 
they can ship better products for the future.” 


Engendering change in a corporate environment isn’t something you can do 
alone, no matter how great a leader you are. Being collaborative about change 
and innovation, and employing the resources already available to help you make 
those changes, is critical. 


“Tap into internal sources of ideas so that every part of the organization is 
involved in the innovation process,” suggests Barry O’Reilly. “This often requires 
a shift in corporate culture—removing the ‘not invented here’ mentality—to 
ensure that intrapreneurs and other leaders are willing to open up to external 
sources of innovation. Be prepared to tell people within the business to consider 
the possibility that another part of the organization might be best placed to 
exploit some of their ideas—together or maybe even without them.” 


SHOWING, NOT TELLING 


“With senior leaders, I constantly try to create scenarios where you can break 
their mental model of the world through safe-to-fail experiments—either testing 
what a new product might be, testing what a new process might be, or actually 
testing some of the changes that they’re trying to make in themselves as a 
leader,” says O’ Reilly. 
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Lead by example and show your team or peers how to live and breathe this user- 
centric, iterative product-development process so that they can truly understand 
how it works, how valuable it is, and how hard it is to execute well. 


Tanya Cordrey, former Chief Digital Officer at the Guardian, adds: “Find a way to 
get some quick wins, and get some metrics moving. Everyone gets really excited 
about that. You should celebrate every time figures go up. You have a job to build 
your own credibility and build your team’s credibility. When you’ve done some of 
those things, everyone gets really excited, and this lets you make a case for bigger 
changes.” 


“Doing iterative and experimental, test-and-learn product development, although 
it looks really simple on paper, is exceptionally hard,” O’Reilly concludes. “Get- 
ting executives and team members to experience that is actually one of the most 
transformative things you can do. They start to empathize with leadership, and 
leadership starts to empathize with the people on the ground about how difficult 
this stuff is, rather than just thinking it’s easy to do these things.” 


MAINTAINING VISION CLARITY 


“The role of the roadmap is to illustrate our vision of where we’re going,” says 
Matt Poepsel, Predictive Index’s Vice President of Product. “I think we’re doing 
some pretty innovative things in this space, and to be honest, a lot of our compet- 
itors are not; they’re sort of stagnant by comparison.” Predictive Index, a work- 
force analytics company that’s been in business for 50 years, generates over 3 
million job seekers and employee assessments every year for more than 5,000 
clients worldwide. “For us, the roadmap is really the culmination of how we 
expect to grow into our vision,” says Poepsel. The key with this roadmap/vision 
matching is that it’s very dynamic and gets reviewed and revised every 90 days. It 
balances the reality of a dynamic, evolving product environment while addressing 
the need to provide a long-term vision. “The first week of each quarter, we'll pro- 
duce the latest version of the roadmap, but it’s actually a 15-month roadmap,” he 
says. This approach balances the counterintuitive requirements for the product 
leader: to focus the team on the distant future while managing for the near 
future. 


Poepsel describes how this works in more detail: “The reason we publish a 15- 
month roadmap is that it recaps what we accomplished during the prior quarter. 
This is huge for us, because sometimes it’s hard to keep up with an organization 
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that is moving very quickly. To answer the question, ‘What did we just do?’ we 
include a 90-day in arrears of what we most recently delivered, and then we out- 
line a forward-looking 12-month forecast of what we believe we’re going to be 
able to deliver within specific timeframes. This way, our partners can be aware of 
what’s coming and make sure that they’re fully versed in what to expect.” 


TAKING A PRODUCT PORTFOLIO APPROACH 


Knowing how to deploy an enterprise organization’s considerable resources in 
the most effective manner is key to successful product leadership there. Because 
every product is different, whether it’s in the idea stage or in a mature stable mar- 
ket, ready for growth or ready to be sunsetted, it’s important to set up your prod- 
uct organization accordingly. A portfolio approach lets you consider all the 
products in a holistic manner while assigning resources to each product accord- 
ing to its current stage and needs. 


Telenor, like IBM and Microsoft, has designed a five-stage system to categorize 
its products internally. From the first stage, where a product is simply an idea 
around a group of users exhibiting similar behavior that needs more research, to 
the final stage, where the product is in a mature state and needs optimization, 
the stages allow Telenor to focus its resources accordingly. 


In the first stage there are going to be a lot of ideas that fail—and that’s OK. By 
staging its resource allocation, Telenor can ensure that only validated ideas pro- 
gress to product development and that only validated products progress to the 
growth and marketing stages. 


Importantly, throughout the five stages, everything they learn is stored in a cen- 
tral database. VP of Product Lisa Long says, “The database has all this informa- 
tion about what kind of stuff we have tried so that other product managers who 
are saying, ‘Td really like to know what we’ve done in education in Bangladesh,’ 
can look it up in the database and find out, ‘Oh, OK, we did do a project on this 
before. This is what we learned.’ It springboards them for the next piece of learn- 
ing they need to make their own product better.” 


THINKING SMALL TO THINK BIG 


There’s nothing more empowering and more likely to drive innovation than 
allowing for entrepreneurship in your organization. And the only way to allow for 
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it is to take executives’ hands off the reins and introduce a level of autonomy 
within your company, at the division, product, and team level. 


Earlier in this book, we discussed how an autonomous cross-functional team that 
is close to the customer, and has the independence to execute its own strategy 
and tactics, is by far the best way to build products people love. But how do you 
enable this at scale? 


Breaking components of your business into smaller parts is an obvious solution. 
Amazon famously adheres to the concept of the two-pizza team, where no team 
is allowed to grow so large that it can’t be fed by two (large) pizzas. With over 
200,000 employees, that’s a lot of teams. 


Trusting smaller teams to solve problems is another approach. Can four people 
at a huge enterprise company make a difference? At Adobe, they do. Talin Wads- 
worth, Adobe’s Product Design Lead for its latest product, Adobe XD, explains 
how such a large company can think small to get big new products out the door. 
As most product people will remember, the story starts with the shift in design 
tools from stalwart products like Photoshop and Illustrator to hybrid tools like 
Fireworks. “It was built for our job,” says Wadsworth, of Firework’s relevance to 
digital product designers. “Although we still had designers using Photoshop, and 
we all used Illustrator to some extent, Fireworks was the ideal tool because you 
didn’t have to think about resolution. You were designing for screens, and this 
was a tool for screens, so you could trust that it was going to be accurate.” Then 
the axe dropped on Fireworks and a small startup called Sketch started threaten- 
ing Adobe’s dominance in the digital design tool market. Fireworks had been a 
small part of the company’s creative tool suite, but the shuttering of the product 
sent ripples of frustration and confusion through the digital design industry. 
This sent a message to Adobe that there was an opportunity to direct new efforts 
to tools that would help designers and product people craft new designs. 


“We missed it,” says Wadsworth. “We knew the end was coming, but at the same 
time, we were exploring all of these other tools to help us do our jobs better.” 
Sketch was already making waves, but designers were also trying to solve the 
problem of how to create new products at the earliest stages and would try any 
prototyping tool they could get their hands on. Keynote seemed to be the favorite 
of many. Wadsworth empathized with this product design challenge: “The 
majority of my work for pretty much a solid year was done in Keynote. In my 
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role, as a lead [product designer] it’s really about doing the early concepting and 
storytelling. I started building in more and more interactivity and more dynamic 
flows to my presentations to my design.” Wadsworth and his team discovered 
that Keynote was a really handy tool to prototype quickly. “Then of course we saw 
what was happening and realized that we need that modern tool,” he says. 
Instead of doing their designs in one app—for example, Photoshop or Sketch— 
and then prototyping in another, the team wanted a single tool to design and 
build their ideas into testable prototypes. Design and prototyping needed to be 
combined. “We started feeling that this was one tool, a design tool that, of course, 
could give pixel-accurate designs that I trust and feel like I can rely on, but with 
the added aspect of prototyping. We wanted motion and interactivity built into 
the DNA of our tool.” 


Product leaders are often challenged by the situation where the tools they use 
influence outcomes. “It’s this chicken-and-egg cycle where there’s a problem, a 
tool comes along, and then once the tool becomes integrated into the process, it 
can influence those outcomes,” says Wadsworth. “If you had a tool that brought 
design and these new features—motion and interactivity—together, you would 
end up with a tool that designers could use to really push the boundaries of inter- 
active design. We started with this need as designers here at Adobe.” 


MAKING IT BEFORE YOU MAKE IT 


The phrase “fake it ’til you make it” has likely motivated many early-stage prod- 
uct teams. As these teams become more established, we recommend going 
beyond this idea and building prototyping into all new idea development. Wads- 
worth says, “Our process began with a real startup feeling. It was four of us, so 
we could talk about something in the morning, implement it, and be testing by 
the end of the day.” He explains that the initial product design work was done in 
Keynote, with the first prototypes trying to address pieces of this puzzle, as there 
was early agreement that the team couldn’t take on the whole task immediately. 
The very first prototypes were simple tools and features focused on screen 
design, in the web browser. “One of the first [prototypes] we made was just a sim- 
ple repeater,” Wadsworth continues. “We knew in UI design that you sometimes 
need to have the ability to quickly lay out repetitive pattern of shapes. With this 
prototype, you could take a shape and then you could repeat it as many times— 
either horizontally or vertically, in rows and columns—as you wanted.” This 
humble approach is necessary in any size organization, but the process of simpli- 
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fying the early prototyping and testing is even more important when there’s an 
embarrassment of riches. Too many resources and not enough constraints can 
make the process bloated and the participants lazy. “We needed some process to 
organize what problems we were going to tackle. There were so many we could 
have been focusing on, but what we chose could be likened to any number of 
processes. Basically we had to prioritize. We had to figure out the story we 
wanted to tell and then we had to figure out how we were going to get there. 
You're bootstrapping it, figuring it out as you go.” 


Even once the prototyping and testing is done, the desire to keep the bootstrap 
mentality should persist. Wadsworth describes how they took the initial validated 
concepts through the next steps: “From there, it was really about generating 
excitement, continuing to refine our story. That was the sexy part. The other parts 
of getting the tool made were really just doing our own work.” Despite the fact 
that Adobe is a large company, it didn’t assume anything about its customers’ 
potential adoption of the tool or their unspoken needs. “We’re a company 
focused on selling creative tools, so we did a lot of work on market and user 
research,” Wadswoth says. “We started showing some of the early prototypes and 
lining up partnerships with external design groups, just showing them and vali- 
dating some of the early concepts that we had.” Adobe attacked this product 
opportunity with the startup mentality to ensure scalable success. 


Pat Petitti, cofounder of Catalant (formerly Hourly Nerd), told us how he was 
able to generate significant traction both internally and with prospective custom- 
ers and investors by continually prototyping new features and concepts: “It 
started out as a 5- or G-page mockup in Keynote, but as time passed it grew into a 
70-page analog of the product we were building behind the scenes.” Ultimately 
Petitti credits the prototype for locking down the company’s largest client, GE, 
and helping to raise $33 million for its emerging project matching platform. 


This type of prototyping can be valuable to companies of almost all sizes— 
whether you’re an established brand like Adobe or a disrupter trying to maintain 
the post-startup momentum like Catalant. 


PART | III 


Working with 
Customers, Agencies, 
Partners, and 
External Stakeholders 


Every business has a solar system of partners, agencies, customers, external 
stakeholders, and vendors that orbit their core business and help them deliver 
value. In these enlightened customer-centric times, it might be more accurate to 
say that each product company is orbiting the customer. Whatever your point of 
view, there are lots of things to consider when you work with people outside your 
immediate team. There are so many different market environments, different 
size companies, and external personas that there could never be a single generic 
solution. What we’ve learned is that product leaders who have the skills to man- 
age stakeholders and partners are more likely to get what they need. Throughout 
this book we’ve discussed strategies and tactics for getting closer to your custom- 
ers. In this part, we broaden this conversation to include all partners in the prod- 
uct creation process. 


Mapping the Partner 
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This chapter will offer suggestions for mapping out your partner landscape. The 
ecology of where the value flows—from partner to customer or constituent to rev- 
enue—will provide new insights. This mapping can take several forms: an expe- 
rience map, a business canvas, or a flow diagram showing where the activities, 
value, and communication flows. Some of these relationships will be added, 
removed, and edited as the company or product grows. This evolution is normal, 
and partner or vendor relationships should be reassessed from time to time. 


There’s no right or wrong way to do an exercise in partner mapping, but the 
experience map format works well. Experience maps are a temporal display of 
the touchpoints and interactions between internal teams and customers. In the 
case of the partners map, the relationship touchpoints would also include the 
partners that provide services or value to the company and product life cycle. 


It’s surprising when we’re consulting to product companies to discover that they 
haven’t done this work, and are unable to clearly explain where the value flows. 
When they see an experience map illustrated for the first time, they are equally 
surprised. What’s important to remember is that although your company might 
have several partners or agencies, it might also be someone else’s external part- 
ner. Take a good look at which players in your network of providers and partners 
are giving or receiving value. This exercise is important for all companies, but for 
the large enterprise it’s essential. As a company grows so does its network, and 
it’s easier to overlook where the value flows. 


Making It Work 


When James Keller joined Portland, Oregon—based Uncorked Studios as a con- 
tractor, it was initially to help the product design studio untangle its shoelaces 
and build some structure around process. Keller’s previous company had been 
acquired by Walmart, where she stayed and developed a reputation as a relation- 
ship process guru. What quickly transpired after she joined the studio was a com- 
plete overhaul of how the agency works with its product leader clients, which 
include Google, Samsung, and Skype. After some initial consulting she joined 
the Uncorked team full time as the executive semiotics director. In this role she 
deployed what would become the equivalent of a strategy practice throughout our 
work. 
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What Keller did aligns with what we recommend to all product leaders working 
with outside firms: elevate exceptional communications to the primary objective. 
Keller calls this strategy client partnership. “It’s such an obvious name it ensures 
we don’t forget what it’s preparing us for,” says Keller. Client partnership isn’t 
just a name, though—it’s the driving concept and methodology behind every- 
thing they do at Uncorked. The client partnership strategy is divided into three 
practice areas: 


Client relationship 
This gets account managers much closer to the client. 


Semiotics 
This is the studio’s version of product strategy. 


Product practice 
This is where action takes over from strategy. 


“This framework gives us the ability to apply a triumvirate of leadership to the 
product building process,” says Keller. How Keller’s team works with the client’s 
product organization is deceptively simple but hard to implement. How they 
deliver these practices is based on the idea that a good relationship is embedded 
in the careful use of language and tools. “The way you communicate and tool the 
process is a signal to how you work and how the client will partner with you,” 
Keller says. In almost every human interaction, language is more important than 
anything else. Cultural and skill differences are quickly overcome when everyone 
is speaking the same language. 


Finding Common Value 


To get both the client team and the studio team on the same page, Keller starts 
with a Q deck. The Q stands for “questions” and provides a checklist of all the 
things each party will need to know about the other for the communication to be 
optimized. The Q deck also elevates the most important questions so the teams 
understand the purpose behind the work. Here are some of the questions she 
asks: 


+ Why are we building this? 
e Why is it important? 


e Will it deliver value? 
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e How will it deliver value? 


e How will the teams know they have been successful? 


What happens if things go wrong? 


« How do we fix problems when we encounter them? 


“You know the most about the product when you know why it’s being built. This 
process applies to internal products and projects,” Keller says. 


The detailed questions and the follow-up conversations described in the client 
partnership framework might seem unnecessarily onerous for teams already bur- 
dened with lots of work. Keller describes the clients’ reactions: “Initially clients 
said, ‘Wait, you’re asking us to do another job on top of this current job?’ and we 
responded, ‘No, you're doing it already, but now we have a framework to connect 
the dots with.’ You see, any leadership job is already an account management job 
but often without all the right language. We’re just making it a common lan- 
guage to ensure we’re all on the same page.” Keller is adamant that if you don’t 
have a communication framework or tools for smart people, you aren’t allowing 
communication to happen correctly. “How do you know what is a priority if there 
is no communication product strategy?” asks Keller. “They need to understand 
what the beating heart of the product is.” By having a singular source for vision, 
the team can march to the same drumbeat. That works for everyone—whether 
it’s the engineers on the client side or designers on our side. 


Trust Is the Glue 


“Building trust starts with making something together,” says Anthony Armen- 
dariz, CEO and Head of Design at Funsize, a product design studio in Austin, 
Texas. “It doesn’t have to be big or complicated, but when you're creating some- 
thing together you're also creating trust.” Armendariz suggests starting relation- 
ships with partners with a small project that will show each side what it’s like to 
work with the other. This trust building is what makes the relationship between 
the studio and the client so much more valuable. Funsize, which designs digital 
products for companies like OpenTable, Groupon, and Dell, believes that their 
clients hire them primarily to innovate, not just iterate. Making a relationship 
work means acknowledging this from the beginning and molding a process that 
will focus on innovation. Arguing for and delivering on a relationship that 
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pushes the limits benefits both the agency and the client. Armendariz suggests 
that product companies that hire design and development studios primarily as a 
talent stopgap ultimately will not see the value of the relationship. Outsourced 
design and development can quickly become a commodity, so the work’s empha- 
sis should always be on either problem solving or strategic innovation. “Our cli- 
ents ask us, ‘How can we leverage the latest ideas and tech to figure out what the 
future will look like?” says Armendariz. 


This final point by Armendariz highlights the most frequently asked question 
about outsourcing: when and where should these external teams be used? We’ll 
discuss the best way and the best time to use consultants, studios, and firms in 
upcoming sections. 


The Value of Customer Input 


“We often face these [client] challenges on projects,” says David Katz, VP of the 
User Experience Practice at Virtusa Polaris. “For example, and somewhat surpris- 
ingly, one of the hardest things to get clients to agree to is to give us access to 
their users.” Katz feels there’s a fearfulness from product companies about let- 
ting their partners talk to their customers: “Often they’ll want us to work through 
a product owner, as opposed to having direct access to users. I learned early on to 
try to find creative ways around that problem. Before I got into consulting, one of 
my formative experiences was when I worked at Cannondale, the bike company, 
back in the late 80s. There was no such thing as UX back then, but I was one of 
the directors of marketing.” Not discouraged by the perceived and real obstacles 
to speaking directly to customers, Katz came up with his own strategies to get 
feedback and insights. 


“I did a couple of things to give us direct access to customers,” he says. “Soon 
after I joined the company, I went to a local bike shop and asked the owner if I 
could work there on Saturdays. For about six months I did just that, as a regular 
employee. I wasn’t the Cannondale rep at the bike shop; I unpacked boxes, and 
worked the sales floor, all that kind of stuff. I got a lot of insights into mundane 
things, like how we pack the boxes that the bike shop receives. This insight led to 
some practical changes around how we did things.” 


Katz demonstrates that it doesn’t take an act of Congress to get access to custom- 
ers. Even global enterprises have some direct access to the user. The product 
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leader just needs to use a little initiative and creativity to get closer to that cus- 
tomer. “Periodically I would grab a stack of warranty cards and I’d randomly call 
a bunch of people,” says Katz. “I’d take an hour a week and call people who had 
bought a bike within the last month or two and ask them how they liked it so 
far.” Katz explains that most people have never received a call from a company 
whose product they just bought. “Oh my God, they were so surprised, and I knew 
that later that day or that weekend when they were out on a ride with their bud- 
dies, they would be telling them: ‘You won't believe this. I got a call a couple days 
ago from this guy from Cannondale who wanted to know how I liked my bike.’ 
So sometimes it’s working around the system in little different ways in order to 
get some of those insights.” 


We love this story. Katz is a terrific example of what product leaders can do with 
limited resources and a little creativity. Most companies try to structure their 
design and development process so that they have an upfront discovery phase. 
This should be done, but it’s not the only part of the discovery process. Initial 
research and discovery is important before you get into detailed design and devel- 
opment, but it won’t expose weaknesses or opportunities for a product that’s 
already out in the wild. For those cases, product teams need to spend time with 
users, observing and asking probing questions. This doesn’t mean bringing 
them into a conference room to interview them; rather, sit at their desk with 
them, watch how they work, see what artifacts they have in their offices, what’s 
on the sticky notes stuck to their monitor, and what hacks they employ to over- 
come the complexities of the systems they’re using. In every user situation there 
will be things they can articulate and things they can’t. In the latter case a skilled 
observer and interviewer can translate those unspoken or poorly articulated 
things into insightful features or nuances to an application’s design. 


We can’t say it enough: get out of the building. Ask real customers, or prospec- 
tive customers, about their experience. Watch them work or play with your prod- 
uct or try to solve the problems you're interested in solving too. We’ve seen 
teams ride along with users in taxis as they head to the airport, help them with 
their shopping, hang out behind a pharmacy counter, and accompany engineers 
as they install wireless routers in NFL stadiums. Data from surveys or analytics 
tracking alone cannot get this kind of high-quality information. What’s more, it’s 
loads of fun and gets you away from your desk. 
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When and Why to Use Consultants 


When working with outside design or development studios, product leaders need 
to decide if they are using these external teams to simply shore up their resources 
or to solve specific problems. There’s a significant difference in these 
approaches. 


A lot has changed in the last few years. Whereas in the past an external studio or 
firm could have been a stopgap for talent to help execute on projects, these days 
it’s not that simple. As we start to round out the decade, our observations are that 
using experts to simply execute on established solutions is not as useful as using 
them to solve complex design or development problems. 


Given everything we’ve discussed in this book, it’s clear that good product leader- 
ship is critical to the success of a company. Yet you can’t always find the people 
resources, leadership, or know-how in-house. Should you give up or wait until 
you find that perfect hire? Of course not. Think of consultants as a window to 
new insights, knowledge, or speed to market. Why learn through trial and error 
when you can learn from an expert in a fraction of the time? 


But engaging consultants to help with your product leadership has its own chal- 
lenges and pitfalls and only works well in either short-term or long-term engage- 
ments. Anything in between risks having the consultant develop a new strategy 
or culture that doesn’t get fully implemented. 


FILLING EXPERIENCE AND TACTICAL GAPS 


If you’re setting up your first product team, hiring your first product leader, or 
simply seeking the advice and mentorship of an experienced product leader, hir- 
ing a consultant can be a great way to get an immediate injection of experience, 
help, and insight. Finding good full-time people isn’t easy. The supply of solid 
product-focused design and development talent has not kept up with demand. 
What’s worse, recruiters and hiring managers have almost no idea how to hire 
for these product-specific positions. Job descriptions are out of touch with what 
fast-growing design companies need. Leaning on advisors and consultants can be 
the way to fill temporary or tactical gaps in your talent pool. 
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MANAGING CHANGE 


Changing a company culture can be difficult, and creating the safe space for 
members of your team to experiment and fail in front of each other can be really 
difficult to do. An experienced facilitator or coach can lead this process—but only 
if they have executive buy-in and a commitment to keep that change going after 
they have left. Bringing in outside facilitation is often the catalyst a team needs to 
break out of an old habit or see a new perspective. 


EMBEDDING OUTSIDE HELP IN YOUR TEAM 


For everything else, a product leader can only function if they are embedded in 
your team for a longer period of time so that they have a chance to follow 
through on all the things we’ve discussed in this book—from building a culture 
of user-centric, iterative ideation to empowering their team with the autonomy to 
follow through on those ideas and own the outcomes. This does not mean they 
have to be sitting side by side with your people. It does mean they have to be part 
of the team. It also means long-term relationships. As we heard from Anthony 
Armendariz, trust is critical for the agency/client relationship to work. That trust 
needs to be built, and the best way to do that is to work closely together on 
projects. Start small if you have to and then scale up as the trust is secured. 


Our advice when using outside talent and consultants is to treat them like they 
are part of your own team. Invest time in getting on to the same page. Train 
them or onboard them if necessary. Make sure you are communicating on the 
same platforms and in the same channels and using the same tools wherever 
possible. It’s no use having your team on Jira and their team on Basecamp to 
manage tasks. Get specific about how you want to communicate. One of the 
things the client service team at Fresh Tilled Soil does is work through a detailed 
client onboarding process called LaunchPad. The questions in the LaunchPad 
questionnaire get down to the finest details. Learning each person’s preferences 
for receiving updates or questions might sound too granular until you need to 
make a last-minute critical decision on a long weekend. When we say embed 
your agency people into your team, we mean embed their processes and commu- 
nications into your team. 


MANAGING PITFALLS 


Of course, as in any complex process, it’s not always going to be sunshine and 
rainbows. On many occasions, and more so in the enterprise, we see consultants 
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hired as a “swoop and poop”: they arrive at the last minute, are not embedded in 
the teams, create roadmaps and requirements, and get paid on every feature that 
gets delivered. We have heard on many occasions that bringing consultants in 
felt like “black ops,” and employees wished that management had considered an 
alternative approach. If you fall in this camp, you will probably prefer working 
with a product leader that is closer to those described in this book. If manage- 
ment is not familiar with the power a truly human-centered product leader can 
bring to the table, they might try to scale or control with a consultancy. A good 
product leader can empower management by making them see that corporate 
strategy really is your product strategy, and if led, trusted, and held accountable, 
will be your best asset. 


Agencies, Design Firms, and Development Shops 


There is a considerable amount of confusion about the value of outsourcing 
product creation work. Depending on which side of the table you're sitting on, 
there is an argument for maintaining all product design and development inside 
an organization, and another for outsourcing it all. Much like the open-versus- 
closed office space debate, this is a media hype story with way too much empha- 
sis on the black and white, and no attention given to the hundreds of shades of 
gray in between. Having worked in digital product creation for decades and inter- 
viewed hundreds of product leaders, we can safely say that neither outsourcing 
everything nor keeping everything in-house is the answer. To understand the 
value of the outsourcing, you must also understand the value of the work to be 
done. 


In a 2013 Forbes article, Ilya Pozin attempts to answer the question, “What does a 
website cost?”' Before Pozin starts to explain the challenges of pricing, he apolo- 
getically admits that after working on 2,000 projects, he “still cannot answer this 
question.” As product leaders who have worked on hundreds of digital design 
and development projects, we feel his pain. Deeply. For as long as we can 
remember, there has been a conversation about the difficulty of measuring a 
project’s value. In fairness to Pozin’s dilemma, it seems the article was aimed at 
smaller projects. Small projects are inherently problematic because the lower end 
of the market is either a) made up of unsophisticated buyers (i-e., those who have 





1 Ilya Pozin, “How Much Does a Website Cost?” Forbes magazine. 
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never been in the market for a website before), b) restricted by a lack of funding, 
or c) faced with a pile of commodity services all offering identical solutions. Find- 
ing a partner that can plan, design, and develop those product assets is way more 
complicated than a simple website project. For the sake of clarity we’re going to 
avoid the commoditized end of the market for now and focus on the upper tiers 
of digital product creation. This would include product-specific agencies, digital 
product design firms, and development shops focused on product engineering.” 


No company is an island. Product companies and partners must work together. 
In this section we will explore how and why things can go wrong, and how to 
avoid those obstacles. Let’s start by looking at what product leaders need to do to 
set themselves and their partners up for success: 


e Acknowledge the necessity of periodic outsourcing. The challenge many 
hiring companies face is understanding the value of outsourced services 
and the impact these investments will have on the finished product. For 
the most part, large, complex web application work undertaken by product 
companies has challenges related to return on investment. There isn’t a 
company in the world that doesn’t rely on some input of value from an 
outside firm, consultancy, or advisor. Working with outsider firms is inevi- 
table, so it’s better to understand how to make the partnership work than 
pretend that your team can do everything alone. 


e Apply current methods for valuing outsourcing. To understand how pro- 
fessional services (e.g., digital product design and development services) 
are valued by the industry, you need look no further than the Project Man- 
agement Triangle. Sometimes called the Iron Triangle, this model com- 
prises three fundamental aspects to designing and building everything: 
cost, scope, and quality. Sometimes scope is replaced with time on the tri- 
angle. The triangle is supposed to guide decisions on where resources can 
be applied or removed from a project. The common refrain is, “Pick two 
because you can’t have all three.” In other words, if you need the project to 
be inexpensive but maintain features, you'll need to sacrifice the quality of 





2 There are lots of combinations of these firms and agencies. It’s rare to see all these services offered with 
quality within a single consultancy, because it’s hard to maintain quality across a broad range of services. 
Unsurprisingly, the more agencies and firms try to be all things to all clients, the more likely they are to 
deliver a poor-quality service. 


3 Check out this Wikipedia article on Project Management Triangle article. 
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the results. For the most part, this is true. It’s extraordinarily difficult to 
produce a great product if the scope is broad and the money is not there. 
The concern for the product leader is that this simple model doesn’t fully 
explain the value of the work being done or the impact of the work on the 
client’s business. However, the triangle itself is not the problem. The prob- 
lem is that the triangle’s practitioners use it, unwittingly, to avoid the work 
of determining the value of a project. As might be obvious, the value of a 
project is never the cost of the hours or the time to delivery. To further 
complicate calculations, it’s not uncommon to hear designers or develop- 
ers remark that quality is almost impossible to determine because it’s sub- 
jective. To avoid having the quality conversation, they then scope projects 
on the cost of time for the required deliverables. We’ve been guilty of 
doing this ourselves, and it’s taken some time to find alternatives that ben- 
efit both sides. 


e Timebox to focus on value. Time is always time, but it can be divided into 
different size chunks. Determining the best bucket of time for each project 
leads to a better management of its value. Hours are a good bucket if 
you're managing a small project with little definition. Weeks, sprints, or 
months work better for larger projects with discernible milestones or a 
defined roadmap. Some firms and agencies have successfully escaped the 
billable hour and moved to broader timeboxes like sprints.4 In develop- 
ment services the man month is also a common measure of effort; this is a 
calculation of the resource cost over a single month. Regardless of the 
period, time is still the common denominator for valuing the services. 
Whether you build from the bottom up and use hours as your time unit, or 
boil it down from salary, you're still using time as the measuring stick. The 
problem with any calculation that’s using time as its foundation is that it 
either ignores or minimizes the other factors that contribute to value. For 
example, how do we calculate the cost of shortcutting research or choosing 
the wrong vendor, or the opportunity cost of not doing the work at all? The 
bottom line is that the “cost of time” approach forces the industry to use 
billable time as its sole basis for calculations. It ignores the essential ques- 
tion of any successful project —was this the best use of my budget? Design 
and dev studios have traditionally used some timeboxed way to value their 





4 Asprint, in Agile methodology, is often a two-week period. 
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services. These may be either hourly, weekly, or monthly rates, but there 
are some exceptions where firms charge a fixed rate for a project. Fixed 
rates are also pegged to time and materials, but in an indirect way. The 
firm estimates the time and materials for a project and then essentially 
bets that it can do it for less time and make a fair profit. This is a gamble 
and can be very risky for the firm and for the client, because if the firm has 
inadequately estimated the project, it can put itself under a massive cash 
flow strain, which in the worst-case scenario could lead to layoffs or even 
bankruptcy. The product leader is then left with an unfinished project. The 
fixed-bid approach can be effective when used for small projects or discrete 
tasks. Our caution is that it is very difficult to make it work on long or com- 
plicated projects with lots of unknowns. 


Realize RFPs aren’t helping anyone. Another method product leaders use 
to determine the price of the work is to have partners’ sell them their 
value. We’re using the word value, but the bidding partner will interpret 
this to mean cost. The buyer (in this case, the product leader) will either 
compare estimates from multiple vendors—for example, in a request for 
proposal (RFP), which is a document that solicits proposal, often made 
through a bidding process, by an agency or company interested in procure- 
ment of a commodity, service or valuable asset, to potential suppliers to 
submit business proposals process—or use internal calculations based on 
internal deadlines and budgets. Neither option is optimal because they 
both lack any understanding of how the tasks will be performed once awar- 
ded to the partner. The outcome of an RFP process can indicate who was 
the cheapest or who had a pre-bid relationship or who ran the best pitch, 
but it cannot tell you who will be the best partner. Internal budgets are 
generally constructed in a vacuum, so they reveal nothing about the actual 
cost of the work required to complete a project. Furthermore, RFPs serve 
only as a source of friction during the project valuation process. Imagine 
for a minute you're in need of some lifesaving surgery. You call several 
doctors’ offices and tell them you have a fixed budget and timeline to work 
with and will be selecting a winner from competitive bids. How do you 
think this scenario ends? The most qualified doctors laugh at your sug- 





5 We use the word partner in preference to vendor simply because it is a partnership. The vendor label 
describes a transactional interaction. Any work done with an outside firm or agency is a collaboration, 
and the success or failure will be based on equanimity and respect. 
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gested process and ignore you. The least qualified doctors low-ball the 
budget to get the work. Good luck with your surgery. When you bid out a 
product creation project to outside firms with a fixed budget and timeline, 
you're doing the same thing. In these situations, the rates used by the out- 
side partner undervalue its effort, and the client’s reliance on the compara- 
tive market rates as the metric simply reinforces this undervaluation. This 
is a lose-lose scenario. If the project is undervalued, the firm or studio will 
fail to meet its obligations, and the client won’t get the quality it desires. 


Recognize that time is not the only value. It’s essential that the product 
leader finds some time to determine the problem statement or discuss 
how their processes can be aligned. There needs to be a discussion about 
what will happen when roadblocks are encountered—which they often are 
—and what the strategy is to remedy that. If this step is missed, then the 
metrics to determine success or progress will probably be wrong or subjec- 
tively determined. Change the measurement, and a different result 
becomes apparent. 


Beware the wrong incentive. A final point on time as a value metric: if 
you’re paying a consultant on the basis of time, then the consultant is 
incentivized to spend more time on the project. In the consultant’s world, 
more time equals more revenue. We’re not suggesting that a partner will 
deliberately overcharge you or fudge the timesheets to get more money, 
but if time is the basis of its billing practice, it benefits the firm to keep 
busy for longer. Also, it’s not hampered by any of your time constraints. 
The problem is that the wrong metric is being measured and rewarded, 
and as we’ve outlined earlier, whatever you measure gets the attention. 


Weigh strategic value versus cost. Determining the cost of the work is not 
the same as determining the value of the work. This is why choosing a 
cheap firm, or allocating the work to an internal option because you think 
it’s cheaper, is becoming increasingly less attractive. As in other indus- 
tries, building an internal team is lengthy and expensive. You wouldn’t 
start your own construction company to build a skyscraper, just as you 
wouldn’t build a car factory because you need a ride to a meeting. We are 
now firmly in an era that has taught us the value of outsourcing to cloud 
services and SaaS (Software as a Service) tools. These days, most progres- 
sive companies will choose to outsource some of the product work, so they 
need a way to manage those relationships effectively. The good news is, 
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there are hundreds of great product design and development partners that 
have been doing this work for decades. They know how to build great prod- 
ucts, and product leaders can take advantage of this skill. “How do we 
deliver value?” asks Andy Budd of Clearleft, a leading product design com- 
pany. “We’re in the talent business. We hire amazing people, and we cre- 
ate an environment where they can do the best work in their career. We’re 
really good at telling who the clients are that we’re going to work best with. 
We deliver value by understanding their problems and solving them in an 
efficient, effective way.” 


EXAMPLE SCENARIOS 


Let’s look at an imagined example of what might happen when the previous tips 
are ignored. Jane is a lead product person of a company that provides a B2B soft- 
ware application to the healthcare industry. The company thinks it needs a new 
mobile app and a refreshed user interface for its web application. Notice we said 
the company thinks it needs these things. Because Jane’s company’s application 
will be used by practitioners on several different handheld devices, this project 
will require several phases of design, development, and testing. Jane starts the 
estimation process by working with her product team and detailing the new fea- 
tures as well as they can. Due to pressure from others in the organization, they 
rush the process and skip testing their assumptions. Because of the looming 
deadlines, they also rely on outdated research and prefer to go directly into 
requirements gathering and scoping. This might seem like an obvious mistake to 
make, and yet this is exactly what happens every single day. Not really knowing 
what each of these creations will ultimately cost, Jane asks around the office and 
hears things like, “When I did a web project at my previous company, we paid 
$XX for that kind of stuff,” or “The last company charged us $XX to build the 
original app, but that was a few years ago.” Jane has led web design projects 
before, but none as large and complicated as this one. In Jane’s mind the stan- 
dard solution to this situation is to hire a consulting company from a shortlist of 
bidders. The work provided by these expert consultants is generally valued by the 
amount of time they would be investing in producing the solution. She gathers 
the proposals, has a few high-level conversations, and then pulls the trigger. She 
still has no idea of the real cost of the work, because the only comparison she has 
made is among vendors pricing against a scope based on the wrong problem. 
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Jane finds herself measuring the work against the cost of time, not value. Meas- 
uring the time a consultant spends on a project is counterproductive. 


So how could Jane have prevented this scenario? First, instead of rushing to 
scope out a project so she can get competitive bids in front of her, Jane needs to 
understand her problem. This is where a good partner can be helpful. By inviting 
a few experts in to discuss the customer feedback or research, Jane can better 
evaluate how these experts think. If she shows potential partners the research 
and gets more suggested solutions than thoughtful questions, she’s probably 
dealing with the wrong people. Great partners always start new project conversa- 
tions with lots of great questions. They try to understand the root causes behind 
the feedback and data before making any suggestions. If Jane invests a little time 
talking to firms and observing their approaches, she can better understand the 
quality of the firm she’s dealing with. 


The product leader’s viewpoint 


On the other side of the table, the product leader needs to value the work in a way 
that balances internal costs and customer value. If they are new to this calcula- 
tion, they might use a market rate to determine the cost of the project. They will 
use this market rate to collect bids and make an apples-to-apples comparison. 
They might even be thinking that if they can do it cheaper internally, they'll go 
that route. Of course, there is no such thing as an apples-to-apples comparison to 
buying something as amorphous as professional services. While using price or 
cost as a way of comparing similar tools or consumables works fairly well, it’s an 
inefficient way to determine value for services. If you needed legal advice, you 
would be better off not hiring a cheap junior lawyer to represent your important 
case. Likewise, hiring an inexpensive, backroom doctor to do exacting surgery on 
a child would be ridiculous. So why hire inexperienced design or development 
teams to build mission-critical products? How we determine value should be true 
for all professional services. Hiring a firm or agency solely because it’s cheap is 
unlikely to deliver the high standard of work your product deserves. 


Consultancies like Clearleft know that as good as they are, not everybody will see 
their value. Value is not objective. As we mentioned, sometimes what is valuable 
today is not valuable tomorrow. It’s got a lot to do with the stage that the com- 
pany is in and what the project looks like. Determining how to estimate the value 
of a product creation project is difficult even with a skilled partner. The possible 
solution to getting an accurate estimate lies in a concept called value-based pricing. 
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There are two ways to look at value-based pricing. The first is the future value 
this work has to the organization (comparable to return on investment, or ROI), 
and the second is the value of the equivalent internal resources required to create 
the output. The latter method is similar to a working capital calculation. In light 
of the fact that it’s very difficult for a company to know the ROI value before the 
start of a project, we should focus on using the second value calculation. 


The idea behind working capital is that a business should always have more 
assets than liabilities. The difference between these two numbers is the working 
capital. Obviously, if you have more liabilities than assets, you can run into prob- 
lems. The goal is to make sure you employ your capital so that you don’t hinder 
your growth opportunities or hurt your cash flow obligations. For a product 
leader to understand the value of a product design and development project, they 
need to know what capital is being employed to make the project success possi- 
ble. Using the working capital model as the value basis allows you to do this 
effectively. 


A project’s value can easily be compared to the cost of what full-time employees 
(FTEs) would be paid to do the same work. Instead of measuring the value of a 
project by the time it takes to build something, the client team would measure 
the value based on the equivalent effort of hiring all those people. Included in 
this calculation would be the time it takes to recruit, onboard, and train those 
people, as well as any expenses or fees like recruiters’ commissions, taxes, health- 
care, or training by an external coach (e.g., Scrum or Lean training). 


Let’s consider an example of value-based pricing using our equivalent internal 
resources methodology. Jeff, the Chief Product Officer at a SaaS business, will be 
starting an overhaul of his web product user experience and associated user 
interfaces. He doesn’t have UX and UI design skills internally. To estimate the 
scope of the project, Jeff makes a shortlist of the problems the project needs to 
solve. He determines these problems are worth solving by running a design 
sprint with his product team and testing a few high-impact solutions. These vali- 
dated solutions are what he’d like to implement. He adds to that the content 
requirements, expert input from his marketing partner, and the time he’ll need 
from his internal team (meetings, reviews, decision points, etc.). Now that Jeff 
has outlined the work ahead, he compares his requirements list to the skills 
those tasks will require to get done. For example, he sees that he’ll need about 
five to six pages of original content on the new page elements that will be created, 
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which will require a copywriter or content expert, neither of whom the company 
employs. He continues to make a list of product people resources he’ll need to 
get this project completed. Here’s what Jeff's hypothetical list looks like: 


Senior UX expert 
User experience planning and architecture 


Senior user interface designer 
Lead visual design and layouts 


User interface designer 
Second visual designer to provide assistance and redundancy 


Senior frontend developer 
Coding of UI and frontend elements 


Project manager 
Project management and administration of the project 


Now that Jeff has a list of the roles he needs, he can estimate what it would cost 
the company to hire those people full time. The cost of each person can be esti- 
mated from public survey data and salary guides on the web. Once he has calcu- 
lated salaries, Jeff still needs to add the cost of hiring. This includes internal 
interview time and recruiter costs (normally 20% of first-year salary), the cost of 
onboarding and training, and the opportunity cost of time lost to this process. 


The next step is for Jeff to find out what it would cost for him to outsource this 
project. He sits down with a few product design and development companies and 
determines the project cost. The fees charged to him by his outsourced partner 
firm would be the completed product’s present value. Keeping in mind that the 
outsourced team can get started right away and there are no long-term costs once 
the project is done, Jeff finds out he can outsource this project for a lot less than 
it would cost to hire FTEs. 


If Jeff were to invest in this team of FTEs, he would have a negative return on his 
investment. In other words, the future value of his investment in permanent 
skills is equal to the completed product’s present value less the initial annual 
investment. What’s more, he may need to carry those costs annually if those 
FTEs remain with the company. There is also no scenario in which hiring, train- 
ing, and retaining talent isn’t going to cost Jeff some time, effort, and money. In 
other words, there are no shortcuts. 
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What does this mean if you are considering something like a product develop- 
ment or an application UI project? Well, if you had a choice between making hir- 
ing decisions that will cost you $500K over the next several months or paying 
$100K for something that will provide a return on your investment over a shorter 
period, you would do the latter. It’s a no-brainer. However, if you determine that 
the value of the full-time team increases significantly even after the project is 
complete, then you would go the FTE route. The constraints are generally related 
to time to market and what the team can be employed on over time. Most start- 
ups don’t have the luxury of time and resources to build a full product team and 
onboard them while their competitors are delivering product to the market. 


Even if the company decided to hire part-timers or freelancers, they are still deal- 
ing with the same expenses and ongoing costs. Because design and development 
part-time staff are in high demand right now, the company would still need to go 
through the search and recruitment process. Hourly fees tend to skew higher 
than salary rates, so there’s no cost saving there. In fact, it might even be more 
expensive to hire part-time designers and developers. Although there are lower 
ongoing costs related to paying benefits, the opportunity cost remains the same. 


For some product managers, having full-time employees and the accompanying 
sense of ownership represents control over the output. Of course, it’s an illusion 
of control, because talent can leave any time. 


The unreasonable “product design is strategic” argument 


We've heard it said that the reason product companies have their own product 
design and development teams is because these activities are strategically impor- 
tant. We agree. What we disagree with, however, is when those activities become 
strategic and for whom they are strategic. In general, strategic value in a product 
company is anything that effectively translates the product vision into customer 
value. 


The creation of a software product goes through many phases. In its early stages 
the product needs to go through fast iterative testing and improvements. Proto- 
types and alpha builds are tactical. They test assumptions and seek evidence for 
traction. In these early stages the best strategic hire you can make is either a full- 
time product manager that can also get their hands dirty or a strategic product 
design team that can get prototypes built and tested in fast cycles. Building a 
product team before you have a product is financially irresponsible. “Sometimes, 
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agencies can do that more effectively than internal teams, partly because the 
Sword of Damocles of cost is hanging over you,” says Bryan Dunn, VP of Product 
Management at Localytics. “Because we effectively work on an immediate basis, 
clients know how much they’re paying, and that brings a level of urgency to both 
sides. That urgency can sometimes be harmful, but more often than not it cre- 
ates a level of focus, and vision, and momentum that is often lacking internally.” 


Lean UX has taught us that going big straight out of the gate is irresponsible at 
best and fatal at worst. The argument that hiring a complete product design and 
development team is an essential and strategic requirement might have been rel- 
evant to the previous generation of software and tech creators, but in an economy 
that has high expectations of value delivery and low tolerance for failure, it holds 
no water. The very reason Lean works well for startups and innovations is 
because it allows you to make relatively small investments for bigger insights and 
gains. 


The solution is not black or white. It is infinitely easier to build a product when 
you separate the evolution of that product into stages. Each stage needs a differ- 
ent set of resources and considerations. Early on in the process, you want to be 
moving fast and keeping risk to a bare minimum. You can do that by working 
with an outsourced strategic partner instead of adding senior headcount to your 
payroll. As you grow you can bring more of those people costs onto the perma- 
nent payroll. When the time is right and you have traction in the market, you can 
hire a full-time design and development team. 


Freelancers or Contractors 


The notion of a freelancer or contractor also has a negative connotation in the 
product world. Freelancers are perceived to be a last resort—after agencies or 
full-time employees—used mostly as a resource to relieve constraints, for early- 
startup cost savings, or as a stopgap for sizeable teams that may not be able to 
find cost-effective talent in time. Our view of freelancers is the opposite, and we 
see the opportunity in, as we say, cultivating your own “outsourced crowd.” This 
term can be used in different contexts, but for the purposes of this example, it is 
having a vetted group of freelancers or contractors. These are independent part- 
ners that you establish a track record with, that you have a highly integral rela- 
tionship with, and who are aligned with your organization’s vision and mission. 
They often care deeply about the work they produce and want to make sure it 
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aligns well with the interest and values of the organization they are serving. It 
takes a tremendous amount of time to curate a talented group of experts. 
Depending on the size of your company and product lines, it’s not uncommon to 
eventually employ several of your contractors as full-time employees as you grow 
into the relationship. We have many close friends working in very sizeable organ- 
izations that depend solely on the contracted role. 


Strategic Partners 


Partner networks are one of the largest assets to a company. Very often they are 
obscured from the product team because they only deal with sales or marketing. 
It is no surprise that many of the largest enterprise companies in the world have 
as much as 30-40% of their top-line revenue coming in from partnership deals 
and alliances. No matter the size of the organization, you want to consider two 
common business models. The first is the sell-through partner strategy. Typically 
this is an offering where a partner would like to be established as a distributor of 
your goods and services. You apply a margin to your offering and create a part- 
nership portal. Many of these portals are off-the-shelf products from companies 
like Salesforce, and require your product and engineering teams to stub in the 
backend. This allows a partner to have an interface to log in and provision your 
product and an offering to sell through this product—in some cases white- 
labeled or cobranded—to its customer base. In any form, this is a big driver in 
revenue, and another point that we feel is critical to your core product offering. 
We mentioned in the enterprise section that a big driver in feature/benefit prod- 
uct builds is really dictated to the teams. In many cases, this shows up in the 
form of partners wanting increased scope of your core product. One way to com- 
bat many of these requests is exposing a sell-through platform in server-side calls 
so that a partner can build some of the solution on its own. 


The second business model to consider, the sell-to partner strategy, might look 
something like Pluralsight’s strategic partnerships. One of those partnerships is 
with MSDN, a very large network of Microsoft experts. Microsoft values this net- 
work as much as Pluralsight does. In this example Pluralsight sells directly to a 
Microsoft customer in partnership with Microsoft. To do this Pluralsight creates 
three cobranded products, a go-to-market playbook that outlines the sales and 
marketing approach, and a content strategy. Some of this partner strategy will 
have products that sit outside the paywall, while others will sit inside MSDN’s 
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and Pluralsight’s paywalls to drive demand and stickiness. This leverages the best 
of both partners to better deliver value to the customer. 


MULTIDIMENSIONAL PEOPLE AND PARTNER SOLUTIONS 


Knowing when to hire full-timers and when to work with a partner is always 
going to be a challenge for product leaders. Either way they go, the struggle is 
real. Here are some of the frustrations we’re hearing from product leaders: 


“We're like most startups; we've got a lot on our plates. We really need to 
hire more design and product folks before we can begin to tackle these 
projects.” 


“I have a lot of open [product] positions and | don’t know where to start 
looking.” 


“Even if we find someone, it’s going to take us months to onboard and 
have them producing.” 


“We need help recruiting very talented devs and designers. Our challenge 
is we're not a sexy San Francisco-based startup, so I'm not sure we can 
attract those types of people.” 


These concerns are not unique to product companies, but they are increasingly 
the reasons that product momentum is slowing or halting. But hiring is only part 
of the solution. The reason why so many leaders and managers are struggling 
with this problem is because they are seeing it from one perspective. This is not a 
one-dimensional problem. 


Let’s start with the assumption that if you have a people need, you need to hire. 
Hiring a full-time employee might not always be the only solution. Most often 
the requirement to fill a vacant spot requires a multidimensional approach. Hir- 
ing for the immediate needs versus the long-term needs will almost always be 
different. Here’s a recent real-world example: 


An edtech company is creating a complex set of online education tools. 
Their immediate need is to prototype, test, and wireframe the initial prod- 
uct designs. Call this the MVP stage, if you will. Their medium-term needs 
are slightly different. Assuming their initial testing goes well, they will be 
hiring a small team of designers and developers to take over from the 
MVP stage and build out the components in higher fidelity. These people 
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will wear a few different hats and need to be overlapping generalists. Their 
long-term needs are to have autonomous teams made up of specialists 
like product managers, UX strategists, UI designers, and engineers to run 
each of the products across the platform. 


This example is no different from what happens in most high-growth companies. 
As any company moves through each stage, it will encounter different chal- 
lenges. 


The immediate needs, defined by what they need done in three to six months, are 
best addressed by a partner that can get up to speed quickly. The company can 
never hope to recruit, hire, and onboard solid talent and then actually create the 
MVP in that short amount of time by itself. So the partner will save them months 
of frustration and replace it with delivering real value. As it gets traction the com- 
pany will need a team that can cover a lot of ground and wear multiple hats. Gen- 
eralists that can design, test, code, and strategize are very useful at this stage. 
That doesn’t mean everyone at this stage has to be a generalist, just that it’s use- 
ful. As the company or product gains momentum, more specialization is 
required. The team might also start to diverge into product-specific teams, 
depending on the platform size. 


MULTIPLE HIRING STRATEGIES FOR THE WIN 


The insight here is that to get where you need to go, quickly and affordably, 
you're going to have to run multiple hiring strategies. It’s very possible a leader 
will hire the external team (freelancers, agencies, consultants) while simultane- 
ously recruiting for fulltime talent and planning for long-term team structures. 
Hiring talent is not a linear approach. 


Great product leaders know they need a pipeline of talent and a multitrack strat- 
egy to get the best people working on the most time-sensitive things. 


To get the momentum you're looking for, ask yourself: 


+ What is the immediate (3-6 months) need to get traction and momentum? 
+ What is the medium term (6-18 months) going to require? 
« What will we need once we have a validated product and customers? 


e How will these phases overlap or run in parallel? 
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e Can we use outside skills to solve tactical and strategic problems while 
building out the core team? 


Final Thoughts on Partnering 


Great product people will also ask questions about the product, the market, and 
the business, but they should also show an interest in the team they will be work- 
ing with. This is also true of partners. A great partner should resemble a great 
product person. Here are a few suggestions for what to look for in a good product 


partner: 


Do they ask questions about the team they will be working with? 


Do they inquire about what makes the team good/interesting/productive? 


Do they ask about your communication style and how you manage your 
team? 


Do they express an understanding of your challenges? 


Do they understand that producing great products can be difficult and 
frustrating, but still want to do the work? 


Final Words 
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We hope this book, and the wisdom of the many product leaders we’ve inter- 
viewed, has helped you better understand what it means to be a product leader, 
and how they launch great products and build successful teams. In a perfect 
world we'd love this book to be a dynamic, ever-updating vessel of insights 
informed by your feedback and suggestions. Alas, this book will go to print, and 
these words will no longer be editable, but we will endeavor to continue to share 
our learnings at this book’s website. 


Of course, product leadership is still a nascent role that will continue to evolve, 
and rapidly. It’s important therefore, to remember the following points. 


Make It Valuable, Feasible, and Usable 


These core principles of product management infuse everything a product leader 
does. From tactics to strategy, from startup to enterprise, product leaders are 
always asking whether this is valuable to the customer and the business, feasible 
to deliver, and delightful to use. 


Maintain a Learner’s Mindset 


As many of our interviewees said, this is a role where being curious and having 
an appetite for new lessons is essential. Whether it’s keeping on top of the latest 
technology, consumer trends, or management ideas, a product leader cannot be 
complacent with the status quo, or they—and their products—tisk being left 
behind. If the sales team’s mantra is “Always be closing,” then the product lead- 
er’s is “Always be learning.” 


Think Outside the Box 


While the technological landscape is rapidly shifting, a fundamental part of the 
product leader’s toolkit is the soft skills of leadership and management. Luckily, 
these social sciences don’t move as fast, and they have thousands of years of his- 
tory to fall back on. Don’t get stuck on the latest management trend in the latest, 
greatest startup. Leadership inspiration and lessons can come from the craziest 
places—from management theory to sports to jazz. 
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Embrace Change 


As we mentioned in the first part of the book, the Agile Manifesto says to value 
“responding to change over following a plan,” and nothing is more apt for the 
product leadership role. There is no silver bullet or magical process that is going 
to solve all the challenges facing us every day, but by embracing change, you set 
your team up with the flexibility to succeed, no matter what gets thrown at you. 


Stay Humble 


You are not the CEO of your product. You are not Steve Jobs. You are not a lone 
genius designing a product from your ivory tower. Never forget that as a product 
leader you are only as good as your team, and setting them up for success and 
giving them the space to do their best is ultimately how you and your product will 
succeed. 
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